1.1.  Abbreviated terms

ACDC

Atmospheric Composition Data Cube

ACDD

Attribute Convention for Data Discovery

ACIS

Applied Climate Information System

ADES

Application Deployment and Execution Service

ADS

Atmosphere Data Store

AP

Application Package

API

Application Programming Interface

AR

Assessment Report

ARD

Analysis Ready Data

ARDC

Analysis Ready Data Cube

AWS

Amazon Web Service

BCSD

Bias Corrected Spatially Downscaled

BRDF

Bidirectional Reflectance Distribution Function

CCI

Climate Change Initiative

CDI

Combined Drought Indicator

CDR

Climate Data Record

CDS

Climate Data Store

CEOS

Committee on Earth Observation Satellites

CF

Climate and Forecast

CGMS

Coordination Group for Meteorological Satellites

CIOOS

Canadian Integrated Ocean Observing System

CMIP

Coupled Model Intercomparison Project

CMR

Common Metadata Repository

CMRA

Climate Mapping for Resilience and Adaptation

COG

Cloud Optimized Geotiff

CRIS

Climate Resilience Information System

CRMA

Climate Mapping for Resilience and Adaptation

CSV

Comma-Separated Values

CWIC

CEOS WGISS Integrated Catalog

C3S

Copernicus Climate Change Service

DEM

Digital Elevation Model

DRI

Decision Ready Indicator

DSW

Drought Severity Workflow

DWG

Domain Working Group

ECMWF

European Centre for Medium-Range Weather Forecasts

ECV

Essential Climate Variable

EDR

Environmental Data Retrieval

EFFIS

European Forest Fire Information System

EMS

Exploitation Platform Management Service

EO

Earth Observation

ER

Engineering Report

ERA5

fifth generation ECMWF atmospheric reanalysis of the global climate

ESA

European Space Agency

ESDC

Earth System Data Cube

ESDL

Earth System Data Laboratory

ESIP

Earth Science Information Partners

EUMETSAT

European Organisation for the Exploitation of Meteorological Satellites

FAIR

Findable, Accessible, Interoperable, Reusable

FAPAR

Fraction of Absorbed Photosynthetically Active Radiation

FME

Feature Manipulation Engine

FOSS4G

Free and Open Source Software for Geospatial

FRP

Fire Radiant Power

FWI

Fire Weather Index

GCM

General Circulation Model

GCOS

Global Climate Observing System

GDO

Global Drought Observatory

GDP

Gross Domestic Product

GHG

Greenhouse Gasses

GML

Geography Markup Language

GMU

George Mason University

GOOS

Global Ocean Observing System

GRACE

Gravity Recovery and Climate Experiment

HDF

Hierarchical Data Format

IFC

International Finance Corporation

IHO

International Hydrographic Organization

IMGW

Polish Institute of Meteorology and Water Management

IOOS

Integrated Ocean Observing System

IoT

Internet of Things

IPCC

Intergovernmental Panel on Climate Change

JRC

Joined Research Center

JSON

JavaScript Object Notation

KML

Keyhole Markup Language

LCRS

Laboratory for Climatology and Remote Sensing

LDN

Land Degradation Neutrality

LOCA

Localized Constructed Analogs

MERRA

Modern Era Retrospective-Analysis for Research and Applications

ML/AI

Machine Learning / Artificial Intelligence

MODIS

Moderate Resolution Imaging Spectroradiometer

MSDI

Marine Spatial Data Infrastructures

NASA

National Aeronautics and Space Administration

NCAR

National Center for Atmospheric Research

NCA4

National Climate Assessment 4

NDVI

Normalized Difference Vegetation Index

NDWI

Normalized Difference Water Index

NetCDF

Network Common Data Form

NOAA

National Oceanic and Atmospheric Administration

NRCan

Natural Resources Canada

OGC

Open Geospatial Consortium

OGE

Open Geospatial Engine

OMSv3

OGC Observations & Measurements 3.0

OPeNDAP

Open-source Project for a Network Data Access Protocol

OSM

OpenStreetMap

QGIS

Quantum Geographic Information System

RCI

Regional Climate Indicator

RCM

Regional Climate Model

RCP

Representative Concentration Pathway

REST

Representational State Transfer

SDG

Sustainable Development Goal

SMA

Soil Moisture Anomaly

SPEI

Standardized Precipitation Evapotranspiration Index

SPI

Standardized Precipitation Index

SQL

Structured Query Language

SR

Surface Reflectance

SSL

Secure Sockets Layer

STAC

SpatioTemporal Asset Catalogs

S3

Simple Storage Service

THREDDS

Thematic Real-time Environmental Distributed Data Services

TIE

Technical Interoperability Experiments

UNFCCC

United Nations Framework Convention on Climate Change

URL

Uniform Resource Locator

USGS

United States Geological Survey

VIIRs

Visible Infrared Imaging Radiometer Suite

WCS

Web Coverage Service

WFV

Wide Field View

WG Climate

Joint Working Group on Climate

WGISS

Working Group on Information Systems and Services

WHI

Wildland-Human Interface

WHU

Wuhan University

WMS

Web Map Service

WPS

Web Processing Service

WUI

Wildland-Urban Interface

XML

Extensible Markup Language

2.1.  The role of the pilot

The goal of this pilot was to enable everyone to take the relevant actions to address climate change and make well informed decisions for climate change adaptation. This includes scientists, decision makers, city managers, as well as politicians. the role of the pilot was to show how to use data from lots of organizations, available at different scales for large and small areas to be integrated with scientific processes, analytical models, and simulation environments. The role was to show the visualization and communication tools to shape the message in the right way for any client. Many challenges can be met through resources that adhere to FAIR principles. FAIR as in: Findable, Accessible, Interoperable, and Reusable. No single organization has all the data we need to understand the consequences of climate change. The OGC Climate Resilience Pilot identifies, discusses, and develops these resources.

The goal was to help the location community develop more powerful visualization and communication tools to accurately address ongoing climate threats such as heat, drought, floods, fires as well as supporting the national determined contributions for greenhouse gas emission reduction. Climate resilience is often considered the use case of our lifetime, and the OGC community is uniquely positioned to accelerate solutions through collective problem solving with this initiative.

Figure 1 — Value chain from raw data to climate information

As illustrated, big, raw data from multiple sources requires further processing in order to be ready for analysis and climate change impact assessments. Applying data enhancement steps, such as bias adjustments, re-gridding, or calculation of climate indicators and essential variables, leads to “Decision Ready Indicators.” The spatial data infrastructures required for this integration should be designed with interoperable application packages following FAIR data principles. Heterogeneous data from multiple sources can be enhanced, adjusted, refined, or quality controlled to provide Science Services data products for Climate Resilience. The OGC Climate resilience pilots also illustrated the graphical exploration of the Decision Ready Indicators. It effectively demonstrated how to design FAIR climate resilience information systems underpinning FAIR Climate Services. The OGC Pilot participants illustrated the necessary tools and the visualizations to address climate actions moving towards climate resilience.

The OGC Climate Resilience Community has a vision to support efforts on climate actions and enable international partnerships (SDG 17), and move towards global interoperable open digital infrastructures providing climate resilience information on users demand. This pilot contributed to establishing an OGC climate resilience concept store for the community where all appropriate climate information to build climate resilience information systems as open infrastructures can be found in one place, be it Information about data services, tools, software, handbooks, or a place to discuss experiences and needs. It covers all phases of Climate Resilience, from initial hazards identification and mapping to vulnerability and risk analysis to options assessments, prioritization, and planning, and ends with implementation planning and monitoring capabilities. These major challenges can only be met through the combined efforts of many OGC members across government, industry, and academia.

2.2.  Objectives

This Pilot has set the stage for a series of follow up activities. It therefore focused on use-case development, implementation, and exploration. It also answered the questions such as:

• What use-cases can be realized with the current data, services, analytical functions, and visualization capabilities that we have? Current data services include for example the Copernicus Services, including Climate Data Store (CDS) https://cds.climate.copernicus.eu/ and Atmosphere Data Store (ADS) https://ads.atmosphere.copernicus.eu/.

• How much effort is it to realize these use-cases?

• What is missing, or needs to be improved, in order to transfer the use-cases developed in the pilot to other areas?

The pilot had. therefore three objectives. First, to better understand what is currently possible with the available data and technology. Second, what additional data and technology needs to be developed in future to better meet the needs of the Climate Resilience Community; and third, to capture Best Practices, and to allow the Climate Community to copy and transform as many use-cases as possible to other locations or framework conditions.

2.3.  Background

With growing local communities, an increase in climate-driven disasters, and an increasing risk of future natural hazards, the demand for National Resilience Frameworks and Climate Resilience Information Systems (CRIS) cannot be overstated. Climate Resilience Information Systems (CRIS) are enabling data-search, -fetch, -fusion, -processing and -visualization. They enable access, understanding, and use of federal data, facilitate integration of federal and state data with local data, and serve as local information hubs for climate resilience knowledge sharing.

CRIS are already existing and operational, like the Copernicus Climate Change Service with the Climate Data Store. CRIS architectures can be further enhanced by providing climate scientific methods and visualization capabilities as climate application packages. Based on FAIR principles, these application packages enable in particular the reusability of CRIS features and capabilities. Reusability is an essential component when goals, expertises, and resources are aligned from the national to the local level. Framework conditions differ across the nations, but application packages enable as much reuse of existing Best Practices, tools, data, and services as possible.

Goals and objectives of decision makers vary at different scales. At the municipal level, municipal leaders and citizens directly face climate-related hazards. Aspects thus come into focus such as reducing vulnerability and risk, building resilience through local measures, or enhancing emergency response. At the state level, the municipal efforts can be coordinated and supported by providing funding and enacting relevant policies. The national, federal, or international level provides funding, science data, and international coordination to enable the best analysis and decisions at the lower scales.

Figure 2 — Schematic synergies within different climate and science services FAIR and open infrastructures

Productivity and decision making are enhanced when climate application packages are exchangeable across countries, organizations, or administrative levels (see Figure 2). This OGC Climate Resilience Pilot is a contribution towards an open, multi-level infrastructure that integrates data spaces, open science, and local-to-international requirements and objectives. It contributes to the technology and governance stack that enables the integration of data including historical observations, real time sensing data, reanalyses, forecasts or future projections. It addresses data-to-decision pipelines, data analysis and representation, and bundles everything in climate resilience application packages. These application packages are complemented by Best Practices, guidelines, and cook-books that enable multi–stakeholder decision making for the good of society in a changing natural environment.

The OGC Innovation Program brings all groups together: The various members of the stakeholder group define use cases and requirements, the technologists and data providers experiment with new tools and data products in an agile development process. The scientific community provides results in appropriate formats and enables open science by providing applications that can be parameterized and executed on demand.

Figure 3 — The OGC Climate Resilience DWG and Pilot brings the climate resilience community together with infrastructure providers, policy makers, commercial companies, and the scientific community

This OGC Climate Resilience Pilot is part of the OGC Climate Community Collaborative Solution and Innovation process, an open community process that uses the OGC as the governing body for collaborative activities among all members. A spiral approach is applied to connect technology enhancements, new data products, and scientific research with community needs and framework conditions at different scales. The spiral approach defines real world use cases, identifies gaps, produces new technology and data, and tests these against the real world use cases before entering the next iteration. Evaluation and validation cycles alternate and continuously define new work tasks. These tasks include documentation and toolbox descriptions on the consumer side, and data and service offerings, interoperability, and system architecture developments on the producer side. It is emphasized that research and development is not constrained to the data provider or infrastructure side. Many tasks need to be executed on the data consumer side in parallel and then merged with advancements on the provider side in regular intervals.

Good experiences have been made using OGC API standards in the past. For example, the remote operations on climate simulations (roocs) use OGC API Processes for subsetting data sets to reduce the data volume being transported. Other systems use OGC STAC for metadata and data handling or OGC Earth Observation Exploitation Platform Best Practices for the deployment of climate application packages into CRIS architectures. Still data handling regarding higher complex climate impact assessments within FAIR and open infrastructures needs to be enhanced. There is no international recommendation or best practice on usage of existing API standards within individual CRIS. It is the goal of this pilot to contribute to the development of such a recommendation, respecting existing operational CRIS that are serving heterogen user groups

Figure 4 — Schematic Architecture of a Climate Resilience Information System. By respecting FAIR principles for the climate application packages the architecture enables open infrastructures to produce and deliver information on demand of the users needs

2.4.  Technical Challenges

Realizing the delivery of Decision Ready Data on demand to achieve Climate Resilience involves a number of technical challenges that have already been identified by the community. A subset will be selected and embedded in use-cases that will be defined jointly by Pilot Sponsors and the OGC team. The goal is to ensure a clear value-enhancement pipeline as illustrated in Figure 1, above. This includes, among other elements, a baseline of standardised operators for data reduction and analytics. These need to fit into an overall workflow that provides translation services between upstream model data and downstream output — basically from raw data, to analysis-ready data, to decision-ready data. The following technical challenges have been identified and will be treated in the focus areas cycles of the Pilot accordingly:

• Big Data Challenge: Multiple obstacles still exist, creating big barriers for seamless information delivery starting from Data Discovery. Here the emergence of new data platforms, new processing functionalities, and thus new products, data discovery remains a challenge. In addition to existing solutions based on established metadata profiles and catalog services, new technologies such as OGC’s Spatio-Temporal Asset Catalog (STAC) and open Web APIs such as OGC API Records will be explored. Furthermore, aspects of Data Access need to be solved where the new OGC API suite of Web APIs for data access, subsetting, and processing are currently utilized very successfully in several domains. Several code sprints have shown that server-side solutions can be realized within days and clients can interact very quickly with these server endpoints, thus development time is radically reduced. A promising specialized candidate for climate data and non-climate data integration has been recently published in the form of the OGC API — Environmental Data Retrieval (EDR). But which additional APIs are needed for climate data? Is the current set of OGC APIs sufficiently qualified to support the data enhancement pipeline illustrated in Figure 1? If not, what modifications and extensions need to be made available? How do OGC APIs cooperate with existing technologies such as THREDDS and OPEnDAP? For challenges of data spaces, Data Cubes have recently been explored in the OGC data cube workshop. Ad hoc creation and embedded processing functions have been identified as essential ingredients for efficient data exploration and exchange. Is it possible to transfer these concepts to all stages of the processing pipeline? How to scale both ways from local, ad hoc cubes to pan-continental cubes and vice versa. How to extend cubes as part of data fusion and data integration processes?

• Cross-Discipline Data Integration: Different disciplines such as Earth Observation, various social science, or climate modeling use different conceptual models in their data collection, production, and analytical processes. How can we map between these different models? What patterns have been used to transform conceptual models to logical models, and eventually physical models? The production of modern Decision-ready information needs the integration of several data sets, including census and demographics, further social science data, transportation infrastructure, hydrography, land use, topography and other data sets. This pilot cycle uses ‘location’ as the common denominator between these diverse data sets and works with several data providers and scientific disciplines. In terms of Data Exchange Formats the challenge is to know what data formats need to be supported at the various interfaces of the processing pipeline? What is the minimum constellation of required formats to cover the majority of use cases? What role do container formats play? Challenging on technical level is also the Data Provenance. Many archives include data from several production cycles, such as IPCC AR 5 and AR 6 models. In this context, long term support needs to be realized and full traceability from high level data products back to the original raw data. Especially in context of reliable data based policy, clear audit trails and accountability for the data to information evolution needs to be ensured.

• Application packages for processing pipelines: With a focus on Machine Learning and Artificial Intelligence which plays an increasing role in the context of data science and data integration. This focus area needs to evaluate the applicability of machine learning models in the context of the value-enhancing processing pipeline. What information needs to be provided to describe machine learning models and corresponding training data sufficiently to ensure proper usage at various steps of the pipeline? Upcoming options to deploy ML/AI within processing APIs to enhance climate services are rising challenges e.g. on how to initiate or ingest training models and the appropriate learning extensions for the production phase of ML/AI. Heterogeneity in data spaces can be bridged with Linked Data and Data Semantics. Proper and common use of shared semantics is essential to guarantee solid value-enhancement processes. At the same time, resolvable links to procedures, sampling & data process protocols, and used applications will ensure transparency and traceability of decisions and actions based on data products. What level is currently supported? What infrastructure is required to support shared semantics? What governance mechanisms need to be put in place?

2.5.  Relevance to the Climate Resilience Domain Working Group

The Climate Resilience DWG will concern itself with technology and technology policy issues, focusing on geospatial information and technology interests as related to climate mitigation and adaptation as well as the means by which those issues can be appropriately factored into the OGC standards development process.

The mission of the Climate Resilience DWG is to identify geospatial interoperability issues and challenges that impede climate action, then examine ways in which those challenges can be met through application of existing OGC Standards, or through development of new geospatial interoperability standards under the auspices of OGC.

Activities to be undertaken by the Climate Resilience DWG include, but are not limited to:

• Identify the OGC interface standards and encodings useful to apply FAIR concepts to climate change services platforms;

• Liaise with other OGC Working Groups (WGs) to drive standards evolution;

• Promote the usage of the aforementioned standards with climate change service providers and policy makers addressing international regional and local needs;

• Liaise with external groups working on technologies relevant to establishing ecosystems of EO Exploitation Platforms;

• Liaise with external groups working on relevant technologies;

• Publish OGC Technical Papers, Discussion Papers or Best Practices on interoperable interfaces for climate change services;

• Provide software toolkits to facilitate the deployment of climate change services platforms.

2.6.  Value Chain from raw data to Information

During this pilot, participants have worked on a number of workflows and architectures focusing on several use cases of floods, droughts, heatwaves, and fires. It requires the usage of Climate Resilience Information Systems where interoperability plays a vital role in producing climate information by enabling seamless integration and exchange of information between data, models, and various components.

The value chain from raw data to climate information (Figure 1) can be clustered in sections according to the value quality. This value chain, often also compared to a conveyor belt can be designed with different component workflows which are developed, analyzed, and described in this pilot. The order of the document, the chapters are reflecting the value chain organizing and processing starting from Raw data to Datacubes (Chapter 3). The following Chapter 4 is pointing out the data refinement from Raw data and Datacubes to Analysis Ready Data (ARD). In this chapter, various data pipelines are considered, how to move raw data first to data cubes for efficient handling and then processing them to ARD, or deriving the ARD directly from the raw data. This is guiding the discussion on the standardization of DataCubes and ARD. Subsequently, Chapter 5, illustrated how to transform ARD to Decision Ready Indicator (DRI) by including an example set of climate indices. The pilot also demonstrated the value-added of high-end 3D visualization combined with artificial-intelligence-enriched simulations for increasing climate resilience and for facilitating the decision-making process. The use cases driven value chain from Data to Visualization is pointed out in Chapter 6. To close an important gap, a strong emphasis has been stressed out to Climate Information and Communication with Stakeholders in Chapter 7 lining out the importance of consultation work to non-technical users to identify their requirements and optimize the information delivery use-case specific on demand. Some of the value chain elements from raw data to visualization are illustrated by Use cases in Chapter 8. And Lessons Learned (Chapter 9) are showcasing the pilots work as well as pointing out challenges with the value chain from raw data to climate information. The final chapter, chapter 10 Recommendations for future climate resilience pilots describes future work.

3.1.  Analysis Ready Data Cubes — user-friendly sharing of climate data records

Climate Data Record (CDR) is a time serie of measurements of sufficient length, consistency, and continuity to determine potential climate variability and change (US National Research Council). These measurements can be obtained through groundbased stations or derived from a long time series of satellite data.

Data Cube (Different approaches): Datacubes organize data into a multi-dimensional structure. They contain typically:

• multidimensional arrays of data (Kopp et al., 2019);

• 4-dimensional array with dimensions x (longitude or easting), y (latitude or northing), time, and bands sharing the same data properties (Appel and Pebesma, 2019)

• where “cube” can be a metaphor to help illustrate a data structure that can in fact be 1- dimensional, 2-dimensional, 3-dimensional, or higher-dimensional. The dimensions may be coordinates or enumerations, e.g., categories (OGC, 2021)

Common (technical) definition of the Data Cube focuses on the data structure aspects exclusively!

Analysis Ready Data (ARD) — are data sets that have been processed to a minimum set of requirements and organized into a form that allows immediate analysis with a minimum of additional user effort and interoperability both through time and with other datasets. ARDs are often representing satellite data (CEOS website).

The idea behind the ARD is, that data providers such as e.g. EUMETSAT or ESA are better suited to do data pre-processing, e.g. atmospheric correction, cloud masking and re-gridding, than users.

Analysis Ready Data Cubes (ARDCs)
ARDs are often made available in the form of data cubes, which focus on a one specific region (e.g. Swiss Data Cube) or thematic application (e.g. EUMETSAT Drought & Vegetation Data Cube (D&V Data Cube)). Data cubes can also be defined by the type of data it includes (e.g. Atmospheric Composition Data Cube (ACDC), Earth System Data Cube (ESDC) + Data Analytics Toolkit (Earth System Data Lab)).
A data cube which contains various climate data records can be generally referred to as Climate Data Cube.

Table 1 — Example Climate Data Cubes

Analysis Ready Data Cubes (ARDCs) play an important role in handling large volumes of data (such as satellite-based CDRs). They are often deployed on different spatial scales and consist of datasets dedicated for particular application. This makes them more accessible, easier to use and less costly for the users.

3.2.  Data cubes to support wildfire risk analysis

To support the pilot activities, Ecere provided, as an in-kind contribution, a deployment of its GNOSIS Map Server implementing several OGC API standards enabling efficient access to data cubes. The API and backend functionality for these data cubes, improved throughout this pilot, are also supporting a Wildland Fire Fuel indicator workflow for the OGC Disaster Pilot taking place until the end of September 2023. As an end goal of that Disaster Pilot, the data cube API should support machine learning prediction for classifying wildland fire fuel vegetation type from Earth Observation imagery. A number of climate datasets and wildland fire danger indices were also made accessible through that same data cube API. Additional machine learning predictions experiments may be performed based on those datasets as well.

The API and datasets were provided in the hope that they would prove useful to other participants and could be part of Technology Integration Experiments (TIEs) for the pilot and other related OGC initiatives. Mainly due to the exploratory nature of this first phase of the pilot, no successful TIE with these resources with other participants were noted during its execution. However, these resources will remain operational, and successful TIEs are expected with them as part of the Disaster Pilot, the OGC Testbed 19 Geo Data Cube tasks as well as future phases of the climate resilience pilot.

3.2.1.  Climate resilience data cubes

During the course of the pilot, the following datasets relevant to climate resilience were optimized and deployed at a data cube API demonstration end-point using the GNOSIS Map Server.

Table 2 — Datasets provided through GNOSIS Map Server data cube API

Data collection	Fields	Temporal interval	Temporal resolution	Spatial extent	Spatial resolution	Additional dimension	Source
ESA sentinel-2 Level-2A	B01..B12, B8A, AOT, WVP, SCL	November 2016 to October 2022	5 days	Global (land only)	10 meters	N/A	COGs and STAC catalogs on AWS
CMIP5 projections (wind speed)	Eastward and Northward wind velocity	2016 to 2025	daily	Global	2.5° longitude x 2° latitude	8 pressure levels	Copernicus Climate Data Store
CMIP5 projections (air temperature)	Air temperature	2016 to 2025	daily	Global	2.5° longitude x 2° latitude	8 pressure levels	Copernicus Climate Data Store
CMIP5 projections (geopotential height)	Geopotential height	2016 to 2025	daily	Global	2.5° longitude x 2° latitude	8 pressure levels	Copernicus Climate Data Store
CMIP5 projections on single level	Near-surface specific humidity, Precipitation, Snowfall flux, Sea level pressure, Surface downwelling shortwave radiation, Daily-mean near-surface wind speed, Average, Minimum and Maximum near-surface air temperature	2016 to 2025	daily	Global	2.5° longitude x 2° latitude	N/A	Copernicus Climate Data Store
ERA5 reanalysis (relative humidity)	Relative humidity	April 1 to 6, 2023	hourly	Global	0.25° longitude x 0.25° latitude	37 pressure levels	Copernicus Climate Data Store
ECMWF CEMS Fire Danger indices	Burning index, Build-up index, Danger risk, Drought code, Duff moisture code, Fire danger severity rating, Energy release component, Fire danger index, Fine fuel moisture code, Forest fire weather index, Ignition component, Initial spread index, Keetch-byram drought index, Spread component	January 2021 to July 2022	daily	Global (except Antarctica)	0.25° longitude x 0.25° latitude	N/A	Copernicus Climate Data Store
Fuel Vegetation Types for Continental United States	Fuel vegetation type	2022 (no time axis)	N/A	Continental U.S.	~20 meters	N/A	landfire.gov

Figure 5 — ESA sentinel-2 Level-2A from COGs and STAC catalogs on AWS

Figure 6 — CMIP5 projections (air temperature) from Copernicus Climate Data Store

Figure 7 — ECMWF CEMS Fire Danger indices from Copernicus Climate Data Store

Figure 8 — Fuel Vegetation Types for Continental United States from landfire.gov

3.2.2.  Overview of supported OGC API standards to access the data

The GNOSIS Map Server implements several published and candidate OGC API standards and is a certified implementation of OGC API — Features as well as OGC API — Processes. This section describes some of these supported standards and illustrates their use with requests for the climate data collections listed above.

3.2.2.1.  OGC API — Common

The OGC API standards form a complementary set of functionality for efficiently accessing data and processing resources, combining together through the OGC API — Common framework. Whereas OGC API — Common — Part 1 standardizes how the API can present a landing page, describe itself and declare conformance to specific standards, Part 2 provides a consistent mechanism to list and describe collections of geospatial data. The following Common resources are available from the GNOSIS Map Server demonstration end-point:

Table 3 — Common resources that are available from the GNOSIS Map Server

Resource	Common Part	URL
Landing page	Part 1	https://maps.gnosis.earth/ogcapi
OpenAPI description	Part 1	https://maps.gnosis.earth/ogcapi/api
Conformance declaration	Part 1	https://maps.gnosis.earth/ogcapi/conformance
List of collections	Part 2	https://maps.gnosis.earth/ogcapi/collections
Collection description	Part 2	https://maps.gnosis.earth/ogcapi/collections/{collectionId}

In addition to the common resources standardized by Part 1 and Part 2, several API building blocks are consistently re-used across the different OGC API standards. The following table summarizes common query parameters supported by several of the data access APIs:

Table 4 — Common query parameters

Query parameter	Description	APIs
subset	For subsetting (trimming or slicing) on an arbitrary dimension	Coverages, Maps, Tiles (except for spatial dimensions), DGGS (zone query; for data retrieval: except for DGGS dimensions)
bbox	For subsetting on spatial dimensions (Features: spatial intersection)	Coverages, Maps, DGGS (zone query), Features
datetime	For subsetting on temporal dimension (Features: temporal intersection)	Coverages, Maps, Tiles, DGGS (data retrieval: except for temporal DGGS), Features
properties	For selecting specific properties to return (range subsetting); deriving new fields (properties) using CQL2 expression	Coverages, Tiles, DGGS, Features
filter	For filtering using a CQL2 expression	Coverages, Maps, Tiles, DGGS, Features
crs	For selecting an output coordinate reference system	Coverages, Maps, Features
bbox-crs	For specifiying the coordinate reference system of the bbox parameter	Coverages, Maps, Features, DGGS
subset-crs	For specifiying the coordinate reference system of the subset parameter	Coverages, Maps, DGGS
width	For specifying the width of the output (resampling)	Coverages, Maps
height	For specifying the height of the output (resampling)	Coverages, Maps

With Coverages and Maps, a spatial area of interest can be specified using either e.g., bbox=10,20,30,40 or subset=Lat(20:40),Lon(10:30).

For temporal datasets, a specific time can be requested using e.g., datetime=2022-03-01 or subset=time("2022-03-01").

For the data cubes with multiple pressure levels, the pressure dimension is defined and can be used with the subset query parameter with all of the data access OGC API standards (Coverages, Tiles, DGGS and Maps) e.g., subset=pressure(500).

3.2.2.2.  OGC API — Coverages

The OGC API — Coverages candidate Standard is a simple API defining fundamental functionality to retrieve access data for arbitrary fields, area, time and resolution of interest from a data cube.

The main resource to retrieve data using the Coverages API is located at /collections/{collectionId}/coverage for each data collection. This resource supports a number of query parameters defined by optional requirements classes and extensions supported by the GNOSIS Map Server:

Table 5 — Supported query parameters defined by optional requirements classes and extensions supported by the GNOSIS Map Server

Query parameter	Description	Requirements class
subset	For subsetting (trimming or slicing) on an arbitrary dimension	Subsetting
bbox	For subsetting on spatial dimensions	Subsetting
datetime	For subsetting on temporal dimension	Subsetting
scale-factor	For resampling using the same factor for all dimensions (1: no resampling, 2: 2x downsampling)	Scaling (resampling)
scale-axes	For resampling using a specific factor for individual dimensions	Scaling (resampling)
scale-size	For resampling by specifying the expected number of cells for each dimension	Scaling (resampling)
width	For specifying the width of the output (resampling)	Scaling (resampling)
height	For specifying the height of the output (resampling)	Scaling (resampling)
properties	For selecting specific properties to return (range subsetting); deriving new fields using CQL2 expression	Range subsetting; Derived fields extension
filter	For filtering using a CQL2 expression	Range filtering extension
crs	For selecting an output coordinate reference system	CRS extension
bbox-crs	For specifiying the coordinate reference system of the bbox parameter	CRS extension
subset-crs	For specifiying the coordinate reference system of the subset parameter	CRS extension

The Coverages draft currently also specifies a DomainSet JSON object which is linked using the [ogc-rel:coverage-domainset] link relation from the collection description, which may be included either within the collection description itself, or at a dedicated resource (/collections/{collectionId}/coverage/domainset). The schema for this DomainSet object describes the domain of the coverage (the extent and resolution of its dimensions / axes) and follows the Coverages Implementation Schema (CIS) 1.1.1. An example of such a domain set resource can be found at https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:byPressureLevel:windSpeed/coverage/domainset?f=json . At the time of writing this report, discussions are underway to potentially simplify the API by fully describing the domain directly within the collection description resource, using uniform additional dimensions, as well as the grid property, inside the extent property, which can describe both regular as well as irregular grids, removing the need for this extra resource. For example, see the collection description for the CMIP5 single pressure level data and its corresponding CIS domain set resource.

The Coverages draft currently also specifies a RangeType JSON object which is linked using the [ogc-rel:coverage-rangetype] link relation from the collection description, which may be included either within the collection description itself, or at a dedicated resource (/collections/{collectionId}/coverage/domainset). The schema for this RangeType object describes the range type of the coverage (the extent and resolution of its dimensions / axes) and follows the Coverages Implementation Schema (CIS) 1.1.1. An example of such a range type resource can be found at https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:byPressureLevel:windSpeed/coverage/rangetype?f=json . It might be possible to also describe the range type in a common way across the different OGC APIs using a JSON schema with semantic annotations, as per the work undertaken for OGC API — Features — Part 5: Schemas.

A Coverage Tiles requirements class is defined in OGC API — Coverages, leveraging the OGC API — Tiles standard while clarifying requirements for coverage tile responses. Example of coverage tiles requests are described below in the OGC API — Tiles section.

At the moment, the GNOSIS Map Server implementation of Coverages is limited to the following 2D (spatial dimensions) output formats:

• GeoTIFF (multiple fields, two-dimensional),

• PNG (single field, 16-bit output, currently using fixed scale (2.98) and offset (16384) modifiers).

There is a plan to add support for n-dimensional output formats, including netCDF, CIS JSON and eventually CoverageJSON as well. For coverages with more than two dimensions, a specific time and/or pressure slice must therefore be selected, currently requiring separate API requests to retrieve a range of time or pressure levels.

Some example of coverage requests:

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/coverage?f=geotiff=tas,tasmax,tasmin,pr,psl=Lat(-90:90),Lon(0:180)=400=2020-05-20 (GeoTIFF coverage with 5 bands for each field)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/coverage?f=geotiff&subset=pressure(750) (GeoTIFF Coverage)

Figure 9 — Coverage request for CMIP5 maximum daily temperature

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/coverage?f=png=(tasmax-250)*400

3.2.2.3.  OGC API — Maps

The OGC API — Maps candidate Standard defines the ability to retrieve a visual representation of geospatial data. The main resource to retrieve data using the Maps API is located at /collections/{collectionId}/map for each data collection. This resource supports a number of query parameters defined by optional requirements classes and extensions supported by the GNOSIS Map Server:

Table 6 — Supported query parameters defined by optional requirements classes and extensions supported by the GNOSIS Map Server

Query parameter	Description	Requirements class
bbox	For subsetting on spatial dimensions	Spatial Subsetting
bbox-crs	For specifiying the coordinate reference system of the bbox parameter	Spatial Subsetting
subset	For subsetting (trimming or slicing) on an arbitrary dimension	Spatial/Temporal/General Subsetting
subset-crs	For specifiying the coordinate reference system of the subset parameter	Spatial/Temporal/General Subsetting
datetime	For subsetting on temporal dimension	Temporal Subsetting
width	For specifying the width of the output (resampling)	Scaling (resampling)
height	For specifying the height of the output (resampling)	Scaling (resampling)
crs	For selecting an output coordinate reference system	CRS
bgcolor	For specifiying the color of the background	Background
transparent	For specifiying whether the background should be transparent	Background
filter	For filtering using a CQL2 expression	Filtering extension

Some example map requests:

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/map?width=2048=pressure(750)=0x002040

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:byPressureLevel:windSpeed/map?subset=pressure(850)=1024

NOTE:    Proper symbolization for this wind velocity map (above request) would require support for wind barbs. In the meantime, the Eastward and Northward velocity are assigned to the green and blue color channels.

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:byPressureLevel:temperature/map?subset=pressure(850)

Figure 10 — Sentinel-2 map (natural color)

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map?subset=Lat(-16.259765625:-16.2158203125),Lon(124.4091796875:124.453125)=2022-06-28

Some example map requests for a specific style, in conjunction with OGC API — Styles:

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/styles/precipitation/map?datetime=2022-09-04

Figure 11 — Sentinel-2 map for NDVI style

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/ndvi/map?subset=Lat(-16.259765625:-16.2158203125),Lon(124.4091796875:124.453125)=2022-04-28

Figure 12 — Sentinel-2 map for Scene Classification Map style

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/scl/map?subset=Lat(-16.259765625:-16.2158203125),Lon(124.4091796875:124.453125)=2022-06-28

A Map Tilesets requirements class is defined in OGC API — Maps, leveraging the OGC API — Tiles stand while clarifying requirements for map tile responses. Example of map tiles requests are described below in the OGC API — Tiles section.

3.2.2.4.  OGC API — Tiles

The OGC API — Tiles Standard defines the ability to retrieve geospatial data as tiles based on the OGC 2D Tile Matrix Set and Tileset Metadata Standard, originally defined as part of the Web Map Tile Service (WMTS) Standard. Unlike WMTS which focused strictly on pre-rendered or server-side rendered Map tiles, the Tiles API was designed to also enable the use of data tiles such as Coverages Tiles and Vector Tiles which can be styled, rendered and used for data analytics performed on the client side. Using pre-determined partitioning schemes facilitates caching for both servers and clients, resulting in more responsive dynamic maps.

The following Tiles API resources are defined:

Table 7 — Tiles API resources

Resource	Requirements Class	Description
…​/tiles	Tilesets list	List of available tilesets
…​/tiles/{tileMatrixSetId}	Tileset	Description of tileset and link to 2D Tile Matrix Set definition
…​/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}	Core	Tiles for a given Tile 2D Matrix Set, tile matrix/row/column

The GNOSIS Map Server supports a number of 2D Tile Matrix Sets for all of the collections it hosts, including:

• the GNOSIS Global Grid (EPSG:4326),

• WorldCRS84Quad (EPSG:CRS84 / EPSG:4326),

• WebMercatorQuad (EPSG:3857),

• WorldMercatorWGS84Quad (EPSG:3395),

• ISEA9R (ISEA),

3.2.2.4.1.  Coverage Tiles

The GNOSIS Map Server currently supports the following coverage tile formats:

• GNOSIS Map Tiles (multiple fields, n-dimensional)

• GeoTIFF (multiple fields, two-dimensional)

• PNG (single field, 16-bit value using fixed scale (2.98) and offset (16384) modifiers)

Support is planned for netCDF, CIS JSON, and eventually CoverageJSON as well as additional formats.

Example coverage tile queries:

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/GNOSISGlobalGrid/3/4/17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/ISEA9Diamonds/4/373/288

To request a different sentinel-2 band than the default RGB (B04, B03, B02) bands:

Figure 13 — Sentinel-2 PNG coverage tile for band 08 (near infra-red)

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/GNOSISGlobalGrid/3/4/17?properties=B08=png

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/ISEA9Diamonds/4/373/288?properties=B08

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/coverage/tiles/WebMercatorQuad/1/1/0?f=geotiff=2022-09-04 (GeoTIFF coverage tile)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/coverage/tiles/WorldCRS84Quad/0/0/0?f=geotiff=pressure(750) (GeoTIFF coverage tile)

3.2.2.4.2.  Map Tiles

The GNOSIS Map Server currently supports the following map tile formats:

• PNG (RGBA)

• JPEG

• GeoTIFF

• GNOSIS Map Tiles

Some example of map tiles queries:

Figure 14 — Sentinel-2 Level-2A map tile for GNOSISGlobalGrid level 3, row 4, column 17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map/tiles/GNOSISGlobalGrid/3/4/17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map/tiles/ISEA9Diamonds/4/373/288

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/map/tiles/WorldCRS84Quad/0/0/0?subset=pressure(750)=0x002040

To get map tiles from a predefined style, in conjunction with OGC API — Styles:

Figure 15 — Sentinel-2 Level-2A map tile using Scene Classification Map style for GNOSISGlobalGrid level 3, row 4, column 17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/scl/map/tiles/GNOSISGlobalGrid/3/4/17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/scl/map/tiles/ISEA9Diamonds/4/373/288

Figure 16 — Sentinel-2 Level-2A map tile using NDVI style for GNOSISGlobalGrid level 3, row 4, column 17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/ndvi/map/tiles/GNOSISGlobalGrid/3/4/17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/ndvi/map/tiles/ISEA9Diamonds/4/373/288

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/styles/precipitation/map/tiles/WebMercatorQuad/1/1/0?datetime=2022-09-04

3.2.2.5.  OGC Common Query Language (CQL2)

The OGC Common Query Language, abbreviated CQL2, allows to define query expressions. Although introduced as a language to specify a boolean predicate for OGC API — Features — Part 3: Filtering, the language is easily extended for additional use cases such as filtering the range set of a coverage request, or to deriving new fields using expressions (that can return non-boolean values) including performing coverage band arithmetics, such as calculating vegetation indices.

Support for CQL2 in the filter parameter is implemented in the GNOSIS Map Server for Coverages, Features, Maps, Tiles as well as DGGS. For example, to request all data from the CMIP5 single pressure level collection where the maximum daily temperature is greater than 300 Kelvins, filter=tasmax>300 (unmatched cells will be replaced by NODATA values).

Support for CQL2 in the properties parameter is currently implemented for Coverages, Tiles and DGGS. For example, the pr precipitation property can be multiplied by a factor of one thousand using properties=pr*1000.

Using a CQL2 expression to filter out the clouds in a map tile:

Figure 17 — Sentinel-2 map tile filtered by Scene Classification Layer to remove clouds (a longer time interval with fewer clouds would be necessary to complete the mosaic)

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map/tiles/GNOSISGlobalGrid/3/4/17?filter=SCL<8 or SCL>10

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map/tiles/ISEA9Diamonds/4/373/288?filter=SCL<8 or SCL>10

Using a CQL2 expression in coverage tile requests to perform band arithmetic computing NDVI:

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/GNOSISGlobalGrid/3/4/17?properties=(B08/10000-B04/10000)/(B08/10000+B04/10000)

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/ISEA9Diamonds/4/373/288?properties=(B08/10000-B04/10000)/(B08/10000+B04/10000)

Figure 18 — Coverage tile request from sentinel-2 computing NDVI

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/GNOSISGlobalGrid/3/4/17?properties=(B08/10000-B04/10000)/(B08/10000+B04/10000)*10000=png

Using a CQL2 expression in a coverage request to multiply the relative humidity and filter resulting values below a threshold (20):

Figure 19 — Coverage request from relative humidity coverage multiplying r by 200 and returning only values where r > 20

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/coverage?f=png=pressure(750),Lat(-90:90),Lon(0:180),time(%222023-04-03%22)=r*200=r%3E20

3.2.2.6.  OGC API — Discrete Global Grid Systems

The OGC API — DGGS candidate Standard allows to retrieve data and perform spatial queries based on hierarchical multi-resolution discrete grids covering the entirety of the Earth. There are three main requirements classes for this standard:

• Core (DGGS definition and zone information resource),

• Zone Data Retrieval (What is here?),

• Zones Query (Where is it?)

The following DGGS API resources are defined:

Table 8 — DGGS API resources

Resource	Requirements Class	Description
…​/dggs	Core	List of available DGGSs
…​/dggs/{dggsId}	Core	Description and link to definition of a specific DGGS
…​/dggs/{dggsId}/zones	Zone Query	For retrieving the list of zones matching a collection and/or query
…​/dggs/{dggsId}/zones/{zoneId}	Core	For retrieving information about a specific zone
…​/dggs/{dggsId}/zones/{zoneId}/data	Data Retrieval	For retrieving data for a specific zone

DGGS API requests imply the use a particular grid understood by both the client and the server, associated with the {dggsId} of the resource on which the request is performed. Several different discrete global grids have been defined. The GNOSIS Map Server currently supports two discrete global grids:

• the GNOSIS Global Grid, based on the 2D Tile Matrix Set of the same name defined in the EPSG:4326 geographic CRS, axis-aligned with latitude and longitude, and using variable width tile matrices to approach equal area (maximum variation is ~48% up to a very detailed zoom level),

• the ISEA9R (Icosahedral Snyder Equal Area aperture 9 Rhombus) grid, a dual DGGS of ISEA3H (aperture 3 hexagonal) for its even levels, using rhombuses/diamonds which, compared to hexagons, are much simpler to index and for which it is much easier to encode data in a rectilinear formats such as GeoTIFF. The area values of ISEA3H hexagons can be transported as points on the rhombus vertices for those ISEA3H even levels. The ISEA9R grid is also axis-aligned to a CRS defined by rotating and skewing the ISEA projection, also allowing to define a 2D Tile Matrix Set for it.

A client will normally opt to use OGC API — DGGS if it shares an understanding and internal use of the same grid with the server. Although for axis-aligned DGGS that can be represented as a 2D Tile Matrix Set OGC API — Tiles can be used to retrieve data for specific zones, the DGGS API enables zone data retrieval for other DGGS which are not axis-aligned or whose geometry makes that impossible (e.g., hexagons). Another important use of the DGGS API is the ability to efficiently retrieve the results of a spatial query (e.g., using CQL2) in the form of a compacted list of zone IDs.

3.2.2.6.1.  Core

The core requirements class defines requirements to list available DGGS, describe each of them and provide information for individual zones.

In the GNOSIS Map Server implementation of the zone information resource, since both supported DGGS also correspond to a 2D Tile Matrix Set, the Level, Row and Column for the equivalent OGC API — Tiles request is displayed on the information page, as can be seen below. For the DGGS {zoneId}, the level, row and column is encoded differently in a compact hexadecimal identifier. Some example zone information requests:

Figure 20 — GNOSIS Map Server information resource for GNOSIS Global Grid zone 5-24-6E

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/GNOSISGlobalGrid/zones/5-24-6E

Figure 21 — GNOSIS Map Server information resource for ISEA9Diamonds zone A7-0

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/ISEA9Diamonds/zones/A7-0

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/ISEA9Diamonds/zones/E7-FAE

3.2.2.6.2.  Zone Data Retrieval: What is here?

The Zone Data Retrieval requirements class allows to retrieve data for a specific DGGS zone. For axis-aligned DGGSs whose zone geometry can be described by a 2D Tile Matrix Set such as the GNOSISGlobalGrid, ISEA9R or rHealPix, this capability is equivalent to Coverage Tiles requests for the corresponding TileMatrixSets. This requirements class supports returning data for zones whose geometry is of an arbitrary shape e.g., hexagonal or triangular. The zone data retrieval resource is …​/dggs/{dggsId}/zones/{zoneId}/data, for which the GNOSIS Map Server supports a number of query parameters:

Table 9 — Query parameters supported by the GNOSIS Map Server

Query parameter	Description
filter	For filtering data within the response using a CQL2 expression
properties	For selecting specific properties to return (range subsetting); deriving new fields using CQL2 expression
datetime	For subsetting on temporal dimension
subset	For subsetting (trimming or slicing) on an arbitrary dimension (besides the DGGS dimensions)
subset-crs	For specifiying the coordinate reference system of the subset parameter
zone-depth	For specifying zone depths to return relative to the requested zone (0 corresponding to a single set of values for the zone itself)

Some example of data retrieval queries:

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/GNOSISGlobalGrid/zones/3-4-11/data

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/ISEA9Diamonds/zones/E7-FAE/data

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones/0-0-3/data?f=geotiff=2023-04-03

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/GNOSISGlobalGrid/zones/0-0-3/data?f=geotiff=2022-09-04

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/ISEA9Diamonds/zones/A7-0/data?f=geotiff=2023-04-03

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/ISEA9Diamonds/zones/A7-0/data?f=geotiff=2022-09-04

3.2.2.6.3.  Zone Queries: Where is it?

The Zone Query requirements class allows to efficiently retrieve the results of a spatial query in the form of compact list of zone IDs. The list can be compacted (the default) by replacing children zones by their parents when all children of that parent are part of the result set. The zone query resource is …​/dggs/{dggsId}/zones, for which the GNOSIS Map Server supports a number of query parameters:

Table 10 — Zone query parameters supported by the GNOSIS Map Server

Query parameter	Description
zone-level	For specifying the desired zone hierarchy level for the resulting list of zone IDs
compact-zones	For specifying whether to return a compact list of zones (defaults to true)
filter	For filtering using a CQL2 expression
datetime	For subsetting on temporal dimension
bbox	For subsetting on spatial dimensions
bbox-crs	For specifiying the coordinate reference system of the bbox parameter
subset	For subsetting (trimming or slicing) on an arbitrary dimension
subset-crs	For specifiying the coordinate reference system of the subset parameter

By creating a kind of mask at a specifically requested resolution level, DGGS Zones Query can potentially greatly help parallelization and orchestration of spatial queries combining multiple datasets across multiple services, allowing to perform early optimizations with lazy evaluation.

NOTE:    There are currently some limitations to the GNOSIS Map Server implementation of the Zones Query requirements class.

Examples of zone queries:

Where is relative humidity at 850 hPa greater than 80% on April 3rd, 2023? (at precision level of GNOSIS Global Grid level 6)

(using the default compact-zones=true where children zones are replaced by parent zone if all children zones are included)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones?subset=pressure(850)=2023-04-03=r%3E80=6=json (Plain Zone ID list output)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones?subset=pressure(850)=2023-04-03=r%3E80=6=uint64 (Binary 64-bit integer Zone IDs)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones?subset=pressure(850)=2023-04-03=r%3E80=6=geotiff (GeoTIFF output)

Figure 22 — GeoJSON output of a GNOSIS Global Grid DGGS Zone Query for relative humidity at 850 hPa greater than 80% on April 3rd, 2023

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones?subset=pressure(850)=2023-04-03=r%3E80=6=geojson

Where is maximum daily temperature greater than 300 degrees Kelvins on September 4, 2022? (at precision level of GNOSIS Global Grid level 6)

(using the default compact-zones=true where children zones are replaced by parent zone if all children zones are included)

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/GNOSISGlobalGrid/zones?filter=tasmax%3E300=2022-09-04=6=json (Plain JSON Zone ID list output)

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/GNOSISGlobalGrid/zones?filter=tasmax%3E300=2022-09-04=6=uint64 (Binary 64-bit integer Zone IDs)

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/GNOSISGlobalGrid/zones?filter=tasmax%3E300=2022-09-04=6=geotiff (GeoTIFF output)

Figure 23 — GeoJSON output of a GNOSIS Global Grid DGGS Zone Query for maximum daily temperature greater than 300 degrees Kelvins on September 4, 2022

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/GNOSISGlobalGrid/zones?filter=tasmax%3E300=2022-09-04=6=geojson

Additional examples of zone queries for a Digital Elevation Model (returning regions where elevation data is available):

https://maps.gnosis.earth/ogcapi/collections/SRTM_ViewFinderPanorama/dggs/ISEA9Diamonds/zones

https://maps.gnosis.earth/ogcapi/collections/SRTM_ViewFinderPanorama/dggs/ISEA9Diamonds/zones?f=json (as a list of compact JSON IDs)

3.2.2.7.  OGC API — Processes — Part 1: Core

The OGC API — Processes standard defines the capability to execute remote processes accepting inputs and returning outputs.

A list of processes is available from the GNOSIS Map Server demonstration end-point at https://maps.gnosis.earth/ogcapi/processes . The following table summarizes the available processes and their current functionality status.

Table 11 — Available processes and their current functionality status for the GNOSIS Map Server

Process	Status	Description
Features Attributes Combiner	Working	This process augments existing vector features with attributes available from a separate feature collection based on an attribute key.
Elevation contours tracer	Working	This process computes contours over an elevation coverage, uniformly spaced by a given vertical distance.
Processes — Core / Modular OGC API Workflows adapter	Working	This process enables the integration of servers supporting OGC API — Processes — Part 1: Core within a modular workflow.
OSM Ecere Routing Engine (OSMERE)	Working	This process computes a route from waypoints based on an OSM roads network.
Maps rendering process	Working	This process renders a map from input data layers.
Passthrough process	Working for features (coverage support to implement)	This process integrates inputs passing them through as an output, providing an opportunity to apply field modifiers.
Echo Process	Working (passing TeamEngine CITE test)	This process accepts any number of input and simply echoes each input as an output.
Point Cloud Gridifier	(Currently requires a local Point Cloud collection, and none is loaded)	Generate a Digital Elevation Model or orthorectified imagery from a point cloud
Point Cloud Elevation	(Currently requires a local Point Cloud collection, and none is loaded)	This process extracts elevation values from a point cloud and applies them as attributes to vector features.
Random Forest Classification	(To be tested again with local sentinel2-l2a collection)	Output random-forest classified image using imagery and training feature dataset
MOAW-WCPS adapter	(To be tested again with WCPS implementation)	This process integrates a WCPS service as part of a Modular OGC API Workflow.

The description of each individual process is available at /processes/{processId}, listing available inputs and outputs, whereas the execution end-point for each process is at /processes/{processId}/execution, supporting a POST operation in which the client includes an execution request as a payload. At this time, only synchronous execution and (Part 3) collection output deferred execution is supported.

A new process is being developed to classify fuel vegetation types using machine learning prediction in the context of the OGC Disaster Pilot 2023. This process will accept as input data from the sentinel-2 Level-2A collection and return fuel vegetation types. The fuel vegetation type coverage for continental United States from landfire.gov will be used as initial training data. This process was not yet operational at the time of writing this report.

3.2.2.8.  OGC API — Processes — Part 3: Workflows and Chaining

The Part 3: Workflows and Chaining candidate Standard extends OGC API — Processes enabling the chaining of nested local and remote processing capabilities, and their integration with local and remote OGC API data collections.

The GNOSIS Map Server currently supports the following extensions defined by Part 3: Workflows and Chaining to the process execution capabilities of Part 1:

• extending execution requests submitted to /processes/{processId}/execution by:

  • referencing local and remote nested processes as inputs ("process"),

  • referencing local and remote OGC API collections as inputs ("collection"),

  • modifying data accessed as inputs and returned as outputs (currently only for the PassThrough process) by filtering with "filter", as well as selecting and deriving fields with "properties",

• requesting output data from virtual OGC API data collections to trigger processing execution (collection output), using response=collection query parameter and value.

Work is ongoing to enhance the data integration capabilities and cross-collection queries to achieve the full potential of Part 3 bringing together local and remote OGC API data and processing capabilities.

4.1.  Transforming climate relevant raw data to ARD

Several past successful OGC testbeds, including the DP 21 to which this pilot is linked, have looked at ARD and IRD but also in terms of use cases. In this pilot, some main technical contributions have been creating digestible OGC data types and formats for specific partner use cases, so producing ARD from publically available EO and model data, including hydrological and other type of model output as well as climate projections.

These ARD will feed into all use cases for all participants, with a particular focus toward the use cases proposed for Heat, Drought and Health Impacts by participants in the pilot.

Specifically, participants provide access to the following satellite and climate projection data:

• Wildfire: Fire Radiant Power (FRP) product from Sentinel 3 (NetCDF), 5p, MODIS products (fire detection), VIIRS (NOAA); possibly biomass availability (fire fuel).

• Land Surface Temp — Sentinel 3

• Pollution — Sentinel 5p

• Climate Projection data (NetCDF, etc., daily downscaled possible): air temp (10 m above ground). Rainfall and possibly wind direction as well

• Satellite-derived Discharge Data to look at Droughts/Floods etc. by basin or other scale

• Hydrological model simulation outputs at (sub)basin scale (within reason)

The created ARD in various OGC interoperable formats created digestible dataflows for the proposed OGC Use Cases. This proposed data chain by several participants is similar to DP21, in which contributors, like RSS-Hydro, SafeSoftware, and others also participated. A generated climate indicator or EO remotely sensed data (NASA, NOAA, ESA, etc.) from various sources are “simplified”to GeoTIFF and / or vectorized geopackage per time step by other participants’ tools, such as the FME software (by SafeSoftware). Another option as an intermediate data type (IRD) can be COG — cloud optimized geotiff which would make access more efficient. The COG GeoTIFFs are optimized for cloud so data sharing can be made more efficient. ARD and IRD should become more service / cloud based wherever possible.

Besides the data format, data structures and semantics required to support the desired DRI’s are important. The time series / raster, and classification to vector contour transform is an approach that worked well in DP21 and has been a good starting point also in this pilot. For example, together in the FME processing engine, time series grids can be aggregated across timesteps to mean or max values, then classify them into ranges suitable for decision making, and then write them out and expose them as time tagged vector contour tables.

In summary, the different ARD and IRD data can be created from the following data sources:

• Inputs: EO (US sources fire related: MODIS, VIIRS); Climate projections, sub catchment polygons, ESA sources; Sentinel-3, Sentinel 5-P.

• Outputs forma & instances: WCS, GeoTIFF spatial / temporal subset, Shape; NetCDF.

• Output parameters: e.g. hydrological condition of a basin (historically/current). So drought / flood etc.

• Output themes: downscaled / subset outputs, hydrologic scenarios.

Another highly relevant input are the Essential Climate Variables (ECV) Inventory (https://climatemonitoring.info/ecvinventory/) houses information on Climate Data Records (CDR) provided mostly by CEOS and CGMS member agencies. The inventory is a structured repository for the characteristics of two types of GCOS ECV CDRs: * Climate data records that exist and are accessible, including frequently updated interim CDRs; * Climate data records that are planned to be delivered.

The ECV Inventory is an open resource to explore existing and planned data records from space agency sponsored activities and provides a unique source of information on CDRs available internationally. Access links to the data are provided within the inventory, alongside details of the data’s provenance, integrity and application to climate monitoring.

Participants, particularly GMU CSISS have demonstrated the use of ECV record information as input with OpenSearch service endpoint (currently CMR(CWIC) and FedEO), and downloading URLs for accessing NetCDF or HDF files.

Outputs in this case include WCS service endpoint for accessing selected granule level product images (GeoTIFF, PNG, JPEG, etc.), focusing on the WCS for downloading images and WMS for showing layers on a basemap.

4.2.  Use of API services for climate related use cases

Pixalytics have developed an OGC-compliant Application Programming Interface (API) service, see Figure 24, which will provide global information on droughts. The approach is to take global open data/datasets from organizations such as ESA/Copernicus, NASA/NOAA, and the WMO and combine meteorology, hydrology, and remote sensing data to produce ARD data based on a composite of different indicators. Where globally calculated drought indicators already exist, these are being used in preference to their re-calculation, although consistency and the presence of uncertainties are also being considered.

Figure 24 — Pixalytics drought severity workflow architecture

The Drought Severity Workflow (DSW) is built using individual drought indicators for precipitation (SPI), soil moisture (SMA), and vegetation drought that are together using the Combined Drought Indicator (CDI) as described by Sepulcre-Canto et al. (2012). The API access has been set up following the Building Blocks for Climate Services approach.

• Component: D100 Drought indicator.

• Inputs: Meteorological data, including Precipitation, plus Land Surface Temperature, Soil Moisture, and Vegetation Index (or optical data to calculate it from).

• Outputs: Drought Indices — default is CDI — as a time-series dataset output in a choice of download able formats: CSV, GeoJSON (default), CoverageJSON and NetCDF for point data and then COG for areas (to be developed).

• What other component(s) can interact with the component: a desire to link to visualization/DRI analysis components. A QGIS plugin called WPS Client has been updated to be able to perform a request and view the outputted JSON file, with and a second QGIS plugin called Data Ploty used to visualize the time-series data. The Web Processing Service (WPS) link to access the drought indicator is: https://api.pixalytics.com/climate/wps?request=GetCapabilities=wps

An example Python query for a location in Canada (Latitude: 55.5 N Longitude: 99.1 W) for the SPI time series, with data for these dates/this location already cached, so runs quicker:

from owslib.wps import WebProcessingService, monitorExecution

	# contact the WPS client
    wps = WebProcessingService("http://api.pixalytics.com/climate/wps", skip_caps=True)

    # GetCapabilities
    wps.getcapabilities()

	# Execute
    inputs = [ ("start_date", '20200101'),
            ("end_date", '20221231'),
            ("latitude", '55.5'),
            ("longitude", '-99.1')]

    execution = wps.execute("drought", inputs, "output")

    outfile = "temp.json"
    monitorExecution(execution,download=True,filepath=outfile)

    # Wait 5 seconds and check
    execution.checkStatus(sleepSecs=5)

    # show status
    print('Percent complete {}%, generated {}'.format(execution.percentCompleted, outfile))

	# If there's an error print the error information
    for error in execution.errors:
        print("Error: ",error.code, error.locator, error.text)

Figure 25 — Drought indicator calling code that generated the default output, which is the CDI in GeoJSON format

• What OGC standards or formats does the component use and produce: Producing data on-the-fly using the WPS, so need to pull data through preferably an API route. The speed that the input data can be made available (i.e., extracting time-series subsets) governs the speed that the drought indicator provides data. To speed this up, input data that is not changing is being cached so that it runs significantly quicker when the API is called for a second time.

Figure 26 shows an example of the output visualized within Python using Streamlit with the intermediate data (cached as NetCDF files) as input.

Figure 26 — Plot of the CDI for a point location in Canada (Latitude: 55.5 N Longitude: 99.1 W); generated using Copernicus Emergency Management Service information [2023]

4.2.1.  Data Sources

The Global Drought Observatory

The Global Drought Observatory (GDO), part of the Copernicus Emergency Management Service, provides a global map of coarsely-gridded agricultural drought risk, along with a breakdown of the risk for each country. The drought risk is computed using the CDI, with the variables used to compute it and other drought-related variables provided in the user portal for download, but the CDI itself is not available for download and so is being calculated in the DSW.

Figure 27 — Global Drought Observatory Web Portal, https://edo.jrc.ec.europa.eu/gdo/php/index.php?id=2001

We obtain SMA and Fraction of Absorbed Photosynthetically Active Radiation (FAPAR) from the GDO data download service. These are provided as netCDF files and contain pre-computed anomalies, so can be assimilated directly into the back-end. The SMA uses a combination of the root soil moisture from the LISFLOOD model, the MODIS land surface temperature and the ESA Climate Change Initiative (CCI) skin soil moisture (https://hess.copernicus.org/articles/21/6329/2017/), and the FAPAR is from NASA optical imagery.

ERA5 Reanalysis from ECMWF CDS

The CDS portal provides an API interface to return either hourly or monthly averages of the ERA5 variables. Requesting the hourly data is necessary to compute anything which requires a frequency greater than monthly, which is the case for most drought indicators (e.g. SMA) which are in dekads. To ensure there is no anti-aliasing, the full 24hr dataset for each day of the month must be downloaded. This is very time-consuming and requests will fail if the number of data points exceeds the limit, which will occur for a period of 2 years or more, even for a single location.

There is a separate application, which can also be accessed via API, to return daily data. The CDS employs a queue management system, which determines the priority of each request based partially on the computational demand of the request. The daily data retrieval relies upon an underlying service to compute the daily statistics from the hourly data, demanding more resources than simply extracting the hourly or monthly data which are pre-computed. This means the request is held in the queue for a long time (up to hours), so there is no time benefit over using the hourly data. However, for a longer time-period which would be rejected if requested hourly, this provides a workaround. A further benefit of requesting daily, rather than hourly, data is that the downloaded file is smaller.

We compute SPI and SMA using variables from the CDS API. The SPI is computed from the total precipitation in monthly intervals. The SMA is computed from the soil water volume, which is available for 4 depth levels. The SMA for each depth is computed by calculating the z-score against a long term mean, using the same baseline time period as the SPI. The most relevant depth layer can then be selected by the user; for instance, a user interested in the health of crops with shallow roots may wish to access the surfacemost layer.

ERA5 Reanalysis from AWS

Input precipitation data was also tested using ERA5 data held within the Registry of Open Data on AWS versus the CDS API and found the Amazon Web Service (AWS) Simple Storage Service (S3) stored data could be accessed faster once virtual Zarrs has been setup, but there is a question over provenance as the data on AWS was put there by an organization other than the data originator and the Zarr approach didn’t work for more recent years as the S3 stored NetCDFs have chunking that is inconsistent. An issue was raised for the Python kerchunck library, to be able to cope with variable chunking, as this isn’t current supported. The issue has also been raised with the organization storing the data on S3, and they are investigating.

NOAA API

The NOAA Climate Environmental Data Retrieval (EDR)

Safe Software extraction of climate forecast data

We reviewed the GeoJSON Feature point data extracted from the Climate scenario RCP4.5 downscaled for Canada provided by Safe Software. As a preliminary test of combining the reanalysis and forecast data the SPI was calculated using reanalysis data up until the end of 2022 and then forecast data for 2023 and 2024; see comparisons in Figure 28.

Figure 28 — Plot of the ECMWF precipitation and SPI, extended using the Canadian climate forecast data, compared to the GDO calculated SPI; generated using Copernicus Emergency Management Service information, Copernicus Climate Service and Canadian Centre for Climate Services data [2023]

4.3.  From Raw Data and Data Cubes to ARD with the FME Platform

4.3.1.  Component Descriptions

D100 — Client instance: Analysis Ready Data Component

Our Analysis Ready Data component (ARD) uses the FME platform to consume regional climate model and generate FAIR analysis ready datasets for downstream analysis and decision support.

The challenge to manage and mitigate the effects of climate change poses difficulties for spatial and temporal data integration. One of the biggest gaps to date has been the challenge of translating the outputs of global climate models into specific impacts at the local level. FME is ideally suited to help explore options for bridging this gap given its ability to read datasets produced by climate models such as NetCDF or OGC WCS and then filter, aggregate, interpolate and restructure it as needed. FME can inter-relate it with higher resolution local data, and then output it to whatever format or service is most appropriate for a given application domain or user community.

Our ARD component supports the consumption of climate model outputs such as NetCDF. It also has the capacity to consume earth observation (EO) data, and the base map datasets necessary for downstream workflows, though given time and resource constraints during this phase we did not pursue consumption of other data types besides climate data.

4.3.1.1.  ARD Workflow

The basic workflow for generating output from the FME ARD component is as follows. The component extracts, filters, interrelates and refines these datasets according to indicator requirements. After extraction, datasets are filtered by location and transformed to an appropriate resolution and CRS. Then the workflow resamples, simplifies and reprojects the data, and then defines record level feature identifiers, climate variable values, metadata and other properties to satisfy the target ARD requirements. This workflow is somewhat similar to what was needed to evaluate disaster impacts in DP21. Time ranges for climate scenarios are significantly longer — years rather than weeks for floods.

Once the climate model, and other supporting datasets have been adequately extracted, prepared and integrated, the final step is to generate the data streams and datasets required by downstream components and clients. The FME platform is well suited to deliver data in formats as needed. This includes Geopackage format for offline use. For online access, other open standards data streams are available, such as GeoJSON, KML or GML, via WFS and OGC Features APIs and other open APIs. For this pilot we generated OGC Geopackage, GeoJSON, CSV and OGC Features API services.

Figure 29 — High level FME ARD workflow showing generation of climate scenario ARD and impacts from climate model, EO, IoT, infrastructure and base map inputs

As our understanding of end user requirements continues to evolve, this will necessitate changes in which data sources are selected and how they are refined, using a model based rapid prototyping approach. We anticipate that any operational system will need to support a growing range of climate change impacts and related domains. Tools and processes must be able to absorb and integrate new datasets into existing workflows with relative ease. As the pilot develops, data volumes increase, requiring scalability methods to maintain performance and avoid overloading downstream components. Cloud based processing near cloud data sources using OGC API web services supports data scaling. Regarding the FME platform, this involves deployment of FME workflows to FME Cloud. Note that in future phases, we are likely to test how cloud native datasets (COG, STAC, ZARR) and caching can be used to scale performance as data transactions and volume requirements increase.

It is worth underlining that our ARD component depends on the appropriate data sources in order to produce the appropriate decision ready data (DRI) for downstream components. Risk factors include being able to locate and access suitable climate models of sufficient quality, resolution and timeliness to support indicators as the requirements and business rules associated with them evolve. Any data gaps encountered are documented under this section under Challenges and Opportunities and in the common Lessons Learned chapter and the end of the ER.

Figure 30 — Environment Canada NetCDF GCM time series downscaled to Vancouver area. From: https://climate-change.canada.ca/climate-data/#/downscaled-data

Figure 31 — Data Cube to ARD: NetCDF to KML, Geopackage, GeoTIFF

Original Data workflow:

1. Split data cube

2. Set timestep parameters

3. Compute timestep stats by band

4. Compute time range stats by cell

5. Classify by cell value range

6. Convert grids to vector contours

Figure 32 — Extracted timestep grids: Monthly timesteps, period mean T, period max T

Figure 33 — Convert raster temperature grids into temperature contour areas by class

Figure 34 — Geopackage Vector Area Time Series: Max Yearly Temp

4.3.1.2.  ARD Development Observations

Figure 35 — FME Data Inspector: RCM NetCDF data cube for Manitoba temperature 2020-2099

Disaster Pilot 2021 laid a good foundation for exploring data cube extraction and conversion to ARD with using the FME data integration platform. A variety of approaches were explored for extraction, simplification and transformation including approaches to select, split, aggregate, and summarize time series. However, more experimentation was needed to generate ARD that can be queried to answer questions about climate trends. This evolution of ARD was one of the goals for this climate pilot. This goal includes better support for both basic queries, and analytics, statistical methods, simplification & publication methods, including cloud native — NetCDF to Geopackage, GeoJSON and OGC, APIs.

In consultation with other participants early in the pilot, we learned that our approach to temperature and precipitation polygons inherited from our work in DP21 on flood contours involved too much data simplification to be useful. For example, contouring required grid classification into segments, such as 5 degree C or 10mm of precipitation etc. However, this effective loss of detail oversimplified the data to the point where it no longer held enough variation over local areas. Based on user feedback, it was determined that simply converting multidimensional data cubes to vector time series point data served the purpose of simplifying the data structure for ease of access, but retained the climate variable precision needed to support a wide range of data interpretations for indicator derivation. It also meant that as a data provider we did not need to anticipate or encode interpretation of indicator business rules into our data simplification process. By simply providing climate variable data points, the end user was free to run queries to find locations and time steps where temp or precipitation are within some threshold of interest.

Initially it was thought that classification rules need to more closely model impacts of interest. For example, the business rules for a heat wave might use a temperature range and stat type as part of the classification process before conversion to vector. However, this imposes the burden of domain knowledge on the data provider rather than on the climate service end user who is much more likely to understand the domain they wish to apply the data to and how best to interpret it.

Figure 36 — Modified ARD Worflow: NetCDF data cube to precipitation point time series in Geopackage for Manitoba

Modified ARD Data workflow:

1. Split data cube

2. Set timestep parameters

3. Compute timestep stats by band

4. Compute time range stats by cell

5. Convert grids to vector points

Figure 37 — Modified ARD Results: Manitoba future precipitation time series points from FME OGC API Feature Service (GeoJSON served from published Geopackage)

Further scenario tests were explored, including comparison with historical norms. Calculations were made using the difference between projected climate variables and historical climate variables. These climate variable deltas may well serve as a useful starting point for climate change risk indicator development. They also serve as an approach for normalizing climate impacts when the absolute units are not the main focus. Interesting patterns emerged for the LA area that we ran this process on deltas between projected and historical precipitation. While summers are typically dry and winters are wet and prone to flash floods. Initial data exploration seemed to show an increase in drought patterns in the spring and fall. More analysis needs to be done to see if this is a general pattern or simply one that emerged from the climate scenario we ran. However, this is the type of trend that local planners and managers may benefit from having the ability to explore once they have better access to climate model scenario outputs along with the ability to query and analyze them.

Figure 38 — Modified ARD Workflow: NetCDF data cube to precipitation delta grids (future - historical) in Geopackage for LA

ARD Climate Variable Delta Data workflow:

1. Split data cubes from historic and future netcdf inputs

2. Set timestep parameters

3. Compute historic mean for 1950 — 1980 per month based on historic time series input

4. Multiply historic mean by -1

5. Use RasterMosaiker to sum all future grids with -1 * historic mean grid for that month

6. Normalize environmental variable difference by dividing by historic average for that month

7. Convert grids to vector points

8. Define monthly environment variables from band and range values

Figure 39 — NetCDF data cube to precipitation delta grids (future - historical) for LA in GeoJSON. This point dataset was fed to other components such as Laubwerk’s visualization component to support interoperability.

More analysis needs to be done with higher resolution time steps — weekly and daily. At the outset monthly time steps were used to make it easier to prototype workflows. Daily time step computations will take significantly more processing time. Future pilots should further explore ways of supporting scalability of processing through automation and cloud computing approaches such as the use of cloud native formats (STAC, COG, ZARR etc).

4.3.1.3.  OGC API Features Service

Compared to OGC WFS2, OGC APIs are a simpler and more modern standard based on a REST and JSON / openAPI approach. However we found implementation of OGC API services somewhat challenging. There seems to be more complexity in terms of number of ways for requesting features, and too many options for representing service descriptions. As every client tends to interpret and use the standard a bit differently — it becomes a challenge to derive how to configure service for a wide range of clients. In particular, QGIS / ArcPro were a challenge to debug given limited logging. For QGIS, we had to examine cache files in the operating system temp directories to look for and resolve errors.

Once correctly configured, OGC API feature services seemed to perform well and likely are more efficient than the equivalent WFS2 / GML feature services. A key aspect of performance improvement was achieving query parameter continuity by passing query settings from the client all the way to the database reader configuration. For example, it was important to make sure the spatial extent and feature limits from the end user client were implemented in the database SQL extraction query and not just at an intermediate stage. We will need to explore better use of caching to further optimize performance. There may also be opportunities for pyramiding time series vector data at a lower resolution for wide area requests. This may better serve those interested in observing large area patterns who don’t necessarily need full resolution at the local level.

It should also be noted that while OGC API services should be a priority for standards support, for a climate and disaster management context, given the relative recent nature of these standards many users may be less than familiar with or prepared to use these standards. As such, there should also be provision to access data directly in well accepted open standards such as GeoJSON, CSV, GeoTIFF, Geopackage or Shape. In this project, some users preferred direct access to GeoJSON or CSV over OGC API access.

Figure 40 — Modified ARD Results: Query result for Manitoba temperature time series points, from FME OGC API Feature Service (GeoJSON served from published Geopackage)

4.4.  A framework example for climate ARD generation

4.4.1.  Component: Surface Reflectance ARD

• Inputs: Gaofen L1A data and Sentinel-2 L1C data

• Outputs: Surface Reflectance ARD

• What other component(s) can interact with the component: Any components requiring access to surface reflectance data

Surface Reflectance (SR) is the fraction of incoming solar radiation reflected from the Earth’s surface for specific incidents or viewing cases. It can be used to detect the distribution and change of ground objects by leveraging the derived spectral, geometric, and textural features. Since a large amount of optical EO data has been released to the public, ARD can facilitate interoperability through time and multi-source datasets. As the probably most widely applied ARD product type, the SR ARD can contribute to climate resilience research. For example, the SR-derived NDVI series can be applied to monitor wildfire recovery by analyzing vegetation index increases. Several SR datasets have been assessed as ARD by CEOS, like the prestigious Landsat Collection 2 Level 2, and Sentinel-2 L2A, while many other datasets are still provided at a low processing level.

WHU is developing a pre-processing framework for SR ARD generation. The framework supports radiometric calibration, geometric ratification, atmospheric correction, and cloud mask. To address the inconsistencies in observations from different platforms, including variations in band settings and viewing angles, we proposed a processing chain to produce harmonized ARD. This will enable us to generate SR ARD with consistent radiometric and geometric characteristics from multi-sensor data, resulting in improved temporal coverage. In the first stage of our mission, we are focusing on the harmonization of Chinese Gaofen data and Sentinel-2 data, as shown in Figure 41, the harmonization involves spatial co-registration, band conversion, and bidirectional reflectance distribution function (BRDF) correction. Figure 42 shows the Sentinel-2 data before and after pre-processing. Furthermore, we wish to seek the assessment of CEOS-ARD in our long-term plan.

Figure 41 — The processing chain to produce harmonized ARD.

Figure 42 — Sentinel-2 RBG composite (red Band4, green Band3, blue Band2), over Hubei, acquired on October 22, 2020. (a) corresponds to the reflectance at the top of the atmosphere (L1C product); (b) corresponds to the surface reflectance after pre-processing.

4.4.2.  Component: Drought Indicator

• Inputs: Climate data, including precipitation and temperature

• Outputs: Drought risk map derived from drought indicator

• What other component(s) can interact with the component: Any components requiring access to drought risk map through OGC API

• What OGC standards or formats does the component use and produce: OGC API — Processes

Drought is a disaster whose onset, end, and extent are difficult to detect. Original meteorological data, such as precipitation, can be obtained through satellites and radar, which can be used for drought monitoring. However, the accuracy is easily affected by detection instruments and terrain occlusion, and the ability to retrieve special shapes, such as solid precipitation, is limited. In addition, many meteorological monitoring stations on the ground can provide local raw meteorological observation data. The SPEI is a model to monitor, quantitatively analyze, and determine the spatiotemporal range of the occurrence of drought using meteorological observation data from various regions. It should supplement the result of drought monitoring with satellite and radar.

SPEI has two main characteristics: 1) it considers the deficits between precipitation and evapotranspiration comprehensively, that is, the balance of water; 2) multi-time scale characteristics. For 1) drought is caused by insufficient water resources. Precipitation can increase water, while evapotranspiration can reduce water. The differences between the two variables simultaneously and in space can characterize the balance of water. For 2), the deficits value of different usable water sources is distinct at different time scales due to the different evolution cycles of different types, resulting in various representations in temporal. By accumulating the difference between precipitation and evapotranspiration at different time scales, agricultural (soil moisture) droughts, hydrological (groundwater, streamflow, and reservoir) droughts, and other droughts can be distinguished by SPEI.

In our project, the dataset for SPEI calculation is ERA5-Land monthly averaged data from 1950 to the present. We selected years of data about partial areas of East Asia for experiments. Through the following flow of the SPEI calculation, we obtain the SPEI value for assessments of drought impact. The flow of the SPEI calculation is shown in Figure 43.

Figure 43 — Flow of the SPEI calculation.

WHU has provided the SPEI drought index calculation services through the OGC API — Processes, enabling interaction with other components. The current endpoint for OGC API — Processes is http://oge.whu.edu.cn/ogcapi/processes_api. This section will explain how to use this API for calculating the drought index.

• Example：/processes http://oge.whu.edu.cn/ogcapi/processes_api/processes The API endpoint for retrieving the processes list.

• Example：/processes/{processId} http://oge.whu.edu.cn/ogcapi/processes_api/processes/spei The API endpoint for retrieving a process description (e.g. spei). This returns the description of “spei” process, which contains the inputs and outputs information.

• Example：/processes/{processId}/execution http://oge.whu.edu.cn/ogcapi/processes_api/processes/spei/execution The API endpoint for executing the process. The spei process exclusively supports asynchronous execution, resulting in the creation of a job for processing. The request body:

{ “inputs”: { “startTime”: “2010-01-01”, “endTime”: “2020-01-01”, “timeScale”: 5, “extent”: { “bbox”: [73.95, 17.95, 135.05, 54.05], “crs”: “http://www.opengis.net/def/crs/OGC/1.3/CRS84” } } }

• Example：/processes/{processId}/jobs/{jobId} http://oge.whu.edu.cn/ogcapi/processes_api/processes/spei/jobs/{jobId} The API endpoint for retrieving status of a job.

• Example：/processes/{processId}/jobs/{jobId}/results http://oge.whu.edu.cn/ogcapi/processes_api/processes/spei/jobs/{jobId}/results The API endpoint for retrieving the results of a job, which are encoded as : [{ “value”: { “time”: “2000_02_01”, “url”: “http://oge.whu.edu.cn/api/oge-python/data/temp/9BC500C1B0E3438C090AF5C6F8602045/8d0357fb-8ffb-4e62-9c3a-55ad17a5831a/SPEI_2000_02_01.png” } }, …​…​ ]

Figure 44 — The SPEI results for the date 2000_02_01.

4.4.3.  Component: Data Cube Infrastructure

• Outputs: Results in the form of GeoTIFF after processing in Data Cubes

• What other component(s) can interact with the component: Any components requiring access to temperature and precipitation data, surface reflectance ARD, and drought risk map in part of Asia through OGC API

• What OGC standards or formats does the component use and produce: OGC API- Coverages, OGC API — Processes

WHU has introduced GeoCube as a cube infrastructure for the management and large-scale analysis of multi-source data. GeoCube leverages the latest generation of OGC standard service interfaces, including OGC API-Coverages, OGC API-Features, and OGC API-Processes, to offer services encompassing data discovery, access, and processing of diverse data sources. The UML model of the GeoCube is given in Figure 5, and it has four dimensions: product, spatial, temporal, and band. Product dimension specifies the thematic axis for the geospatial data cube using the product name (e.g. ERA5_Precipitation or OSM_Water), type (e.g. raster, vector, or tabular), processes, and instrument name. For example, the product dimension can describe optical image products by recording information on the instrument and band. Spatial dimension specifies the spatial axis for the geospatial data cube using the grid code, grid type, city name, and province name. The cube uses a spatial grid for tiling to enable data readiness in a high-performance form. Temporal dimension specifies the temporal axis for the geospatial data using the phenomenon time and result time. Band dimension describes the band attribute of the raster products according to the band name, polarization mode that is reserved for SAR images, and product-level band. The product-level band is the information that is extracted from the original bands. For example, the Standardized Precipitation Evapotranspiration Index (SPEI) band is a product-level band that takes into account the hydrological process and evaluates the degree of drought by calculating the balance of precipitation and evaporation.

Figure 45 — The UML model of WHU Data Cube.

WHU has organized ERA5 temperature and precipitation data, surface reflectance ARD, and drought risk map into cubes and offers climate data services through the OGC API — Coverages, and OGC API — Processes. The API endpoint of Processes has given in the previous chapter. The API endpoint of Coverages is http://oge.whu.edu.cn/ogcapi/coverages_api, allowing users to query and retrieve the desired data from the cube. This section provides examples demonstrating how to access the data from the cube using OGC API — Coverages.

• Example：/collections http://oge.whu.edu.cn/ogcapi/coverages_api/collections?bbox=112.65942,29.23223,115.06959,31.36234=10=2016-01-01T02:55:50Z/2018-01-01T02:55:50Z The API endpoint for querying datasets from the cube, and the query parameters including limit, bbox, and time.

• Example：/collections/{collectionId} http://oge.whu.edu.cn/ogcapi/coverages_api/collections/2m_temperature_201602 The API endpoint for retrieving the description of the coverage with the specified ID from the cube.

• Example：/collections/{collectionId}/coverage http://oge.whu.edu.cn/ogcapi/coverages_api/collections/2m_temperature_201602/coverage The API endpoint for retrieving the coverage in GeoTIFF format for the specified ID. Here is an example of the response:

Figure 46 — The coverage with the ID "2m_temperature_201602" in the Asian region.

• Example：/collections/{collectionId}/coverage/rangetype http://oge.whu.edu.cn/ogcapi/coverages_api/collections/2m_temperature_201602/coverage/rangetype The API endpoint for accessing the range type of the coverage, which is part of the band dimension members in the cube. In this example, the coverage consists of only one band dimension member.

• Example：/collections/{collectionId}/coverage/domainset http://oge.whu.edu.cn/ogcapi/coverages_api/collections/2m_temperature_201602/coverage/domainset The API endpoint for the domain set of the coverage, which is also the domain set of the cube.

4.5.  Climate Resilience Data

4.5.2.  Climate Indices

To provide a more approachable context to future climate, a collection of 47 indices of future temperature and precipitation are computed. These indices build upon prior work on Climdex indices and additional indices developed for National Climate Assessment 4 (NCA4).

• Cooling Degree Days: Cooling degree days (annual cumulative number of degrees by which the daily average temperature is greater than 65°F) [degree days (degF)]

• Consecutive Dry Days: Annual maximum number of consecutive dry days (days with total precipitation less than 0.01 inches)

• Consecutive Dry Days Jan Jul Aug: Summer maximum number of consecutive dry days (days with total precipitation less than 0.01 inches in June, July, and August)

• Consecutive Wet Days: Annual maximum number of consecutive wet days (days with total precipitation greater than or equal to 0.01 inches)

• First Freeze Day: Date of the first fall freeze (annual first occurrence of a minimum temperature at or below 32degF in the fall)

• Growing Degree Days: Growing degree days, base 50 (annual cumulative number of degrees by which the daily average temperature is greater than 50°F) [degree days (degF)]

• Growing Degree Days Modified: Modified growing degree days, base 50 (annual cumulative number of degrees by which the daily average temperature is greater than 50°F; before calculating the daily average temperatures, daily maximum temperatures above 86°F and daily minimum temperatures below 50°F are set to those values) [degree days (degF)]

• Growing-season: Length of the growing (frost-free) season (the number of days between the last occurrence of a minimum temperature at or below 32degF in the spring and the first occurrence of a minimum temperature at or below 32degF in the fall)

• Growing Season 28F: Length of the growing season, 28°F threshold (the number of days between the last occurrence of a minimum temperature at or below 28°F in the spring and the first occurrence of a minimum temperature at or below 28°F in the fall)

• Growing Season 41F: Length of the growing season, 41°F threshold (the number of days between the last occurrence of a minimum temperature at or below 41°F in the spring and the first occurrence of a minimum temperature at or below 41°F in the fall)

• Heating Degree Days: Heating degree days (annual cumulative number of degrees by which the daily average temperature is less than 65°F) [degree days (degF)]

• Last Freeze Day: Date of the last spring freeze (annual last occurrence of a minimum temperature at or below 32degF in the spring)

• Precip Above 99th pctl: Annual total precipitation for all days exceeding the 99th percentile, calculated with reference to 1976-2005 [inches]

• Precip Annual Total: Annual total precipitation [inches]

• Precip Days Above 99th pctl: Annual number of days with precipitation exceeding the 99th percentile, calculated with reference to 1976-2005 [inches]

• Precip 1in: Annual number of days with total precipitation greater than 1 inch

• Precip 2in: Annual number of days with total precipitation greater than 2 inches

• Precip 3in: Annual number of days with total precipitation greater than 3 inches

• Precip 4in: Annual number of days with total precipitation greater than 4 inches

• Precip Max 1 Day: Annual highest precipitation total for a single day [inches]

• Precip Max 5 Day: Annual highest precipitation total over a 5-day period [inches]

• Daily Avg Temperature: Daily average temperature [degF]

• Daily Max Temperature: Daily maximum temperature [degF]

• Temp Max Days Above 99th pctl: Annual number of days with maximum temperature greater than the 99th percentile, calculated with reference to 1976-2005

• Temp Max Days Below 1st pctl: Annual number of days with maximum temperature lower than the 1st percentile, calculated with reference to 1976-2005

• Days Above 100F: Annual number of days with a maximum temperature greater than 100degF

• Days Above 105F: Annual number of days with a maximum temperature greater than 105degF

• Days Above 110F: Annual number of days with a maximum temperature greater than 110degF

• Days Above 115F: Annual number of days with a maximum temperature greater than 115degF

• Temp Max 1 Day: Annual single highest maximum temperature [degF]

• Days Above 32F: Annual number of icing days (days with a maximum temperature less than 32degF)

• Temp Max 5 Day: Annual highest maximum temperature averaged over a 5-day period [degF]

• Days Above 86F: Annual number of days with a maximum temperature greater than 86degF

• Days Above 90F: Annual number of days with a maximum temperature greater than 90degF

• Days Above 95F: Annual number of days with a maximum temperature greater than 95degF

• Temp Min: Daily minimum temperature [degF]

• Temp Min Days Above 75F: Annual number of days with a minimum temperature greater than 75degF

• Temp Min Days Above 80F: Annual number of days with a minimum temperature greater than 80degF

• Temp Min Days Above 85F: Annual number of days with a minimum temperature greater than 85degF

• Temp Min Days Above 90F: Annual number of days with a minimum temperature greater than 90degF

• Temp Min Days Above 99th pctl: Annual number of days with minimum temperature greater than the 99th percentile, calculated with reference to 1976-2005

• Temp Min Days Below 1st pctl: Annual number of days with minimum temperature lower than the 1st percentile, calculated with reference to 1976-2005

• Temp Min Days Below 28F: Annual number of days with a minimum temperature less than 28degF

• Temp Min Max 5 Day: Annual highest minimum temperature averaged over a 5-day period [degF]

• Temp Min 1 Day: Annual single lowest minimum temperature [degF]

• Temp Min 32F: Annual number of frost days (days with a minimum temperature less than 32degF)

• Temp Min 5 Day: Annual lowest minimum temperature averaged over a 5-day period [degF]

The individual web services of climate indices and raster data for download can be accessed at: https://resilience.climate.gov/pages/climate-model-content-gallery

Or for each scenario:

• Historical: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-historical/about

• RCP 4.5 Early Century: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-rcp-4-5-early-century/about

• RCP 4.5 Mid Century: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-rcp-4-5-mid-century/explore?location=34.597533%2C-95.830000%2C5.00

• RCP 4.5 Late Century: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-rcp-4-5-late-century/about

• RCP 8.5 Early Century: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-rcp-8-5-early-century/about

• RCP 8.5 Mid Century: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-rcp-8-5-mid-century/about

• RCP 8.5 Late Century: https://resilience.climate.gov/maps/nationalclimate::u-s-climate-thresholds-loca-rcp-8-5-late-century/explore?location=34.561983%2C-95.830000%2C5.00

The data can be viewed directly in the online map viewer or opened in ArcGIS Online, ArcGIS Desktop, or a StoryMap. To view in other softwares GeoService and KMZ URLs are on the right side of the page under View API Resources.

Figure 47 — View API Resources

5.1.  Wildfire hazard component

To develop its component, Intact migrated its previous proprietary wildfire hazard model to a private on-premise data science environment. For key inputs to the model, external connections to several open data repositories were established. To facilitate these access tests, several public open source datasets, such as climate model outputs, Earth observations, weather and geospatial, were vetted by the appropriate cybersecurity boards. The tests also informed experts of changes in platforms offerings, of new data products specifications, applicable licenses, and of current authoritative scientific references.

Figure 48 — Two samples of IFC’s current national wildfire hazard map

The table below shows the datasets accessed by Intact during the pilot.

Table 12 — Technical Interoperability Experiments (TIE) Table

Below is a summarized list of the key datasets required to produce or update a wildfire hazard map.

• National fire database polygon data

• Fire Weather Index (FWI) daily maps

• Land cover maps

• Drought conditions

• Digital Elevation Model (DEM)

• Population density

• Fuel and vegetation data

Intact’s wildfire hazard map is developed exclusively for internal use. Aside from intellectual property terms, it is meant to be deployed in highly secured data environments, and as such it cannot readily interact with other components of the pilot at this point of time. The intent is to develop geospatial infrastructures and legal terms that would allow a closer collaboration with pilot’s participants.

Very early in the project, Intact also developed an H3 synthetic exposure dataset (see next figure) composed of 14M points spread out across the country in a statically representative pattern. The purpose of this dataset was to facilitate visualization and analysis of the exposure. It was also supposed to allow pilot participants to have a common exposure reference on which to develop decision-ready use cases for insurance, thus advancing towards standardization. Unfortunately, time constraints prevented update and sharing of this dataset.

Figure 49 — IFC’s exposure synthetic dataset, with Montreal – Ottawa corridor on the left, and close-up of Montreal on the right. Color scale represent relative risk density in each cell, while points are representative individual risks

5.2.  The Blue Economy

Pelagis’ participation in the Climate Resilience pilot focuses on enhancing our view of a global oceans observation system by combining real-world ground observations with analysis ready datasets. Monitoring aspects of our oceans through both a temporal and spatial continuum while providing traceability through the observations process allows stakeholders to better understand the stressors affecting the health of our oceans and investigate opportunities to mitigate the longer term implications related to climate change.

The approach to address the needs for a sustainable ocean economy is to make Marine Spatial Planning a core foundation on which to build out vertical applications. Pelagis’ platform is based on a federated information model represented as a unified social graph. This provides a decentralized approach towards designing various data streams each represented by their well-known and/or standardized model. To date, service layers based on the OGC standards for Feature, Observations & Measurements, and Sensors APIs have been developed and extended for adoption within the marine domain model. Previous work provides for data discovery and processing of features based on the IHO S-100 standard (Marine Protected Areas, Marine Traffic Management, …); NOAA open data pipelines for major weather events (Hurricane Tracking, Ocean Drifters, Saildrones …); as well as connected observation systems as provided by IOOS and its Canadian variant, CIOOS.

5.3.  DRI: Heat Impact and Drought Impact FME Components

The following subsections cover the heat and drought impact components developed by Safe Software using the FME platform. For more information on the ARD component these depend on see the 4.3 section on Data Cube to ARD with FME.

5.3.1.  Heat Impact DRI Component

This component takes the climate scenario summary ARD results from the ARD component and analyzes them to derive estimated heat impacts over time, based on selected climate scenarios. Central to this is the identification of key heat impact indicators required by decision makers and the business rules needed to drive them. Process steps include data aggregation and statistical analysis of maximum temperature spikes, taking into account the cumulative impacts of multiple high temperature days. Heat exhaustion effects are likely dependent on duration of heat spells, in addition to high maximum temperatures on certain days.

Figure 51 — ARD Query: Monthly Max Temp Contours

Figure 52 — ARD Query: Max Mean Monthly Temp > 25C

Figure 53 — Town of Lytton - location where entire town was devastated by fire during the heat wave of July 2021 - same location highlighted in ARD query from heat risk query in previous figure

5.3.2.  Drought Impact DRI Component and Interoperability with Other Components

This component takes the climate scenario summary ARD results from the ARD component and analyzes them to derive estimated drought risk impacts over time based on selected climate scenarios. It also feeds drought related environmental factors to other pilot DRI components for more refined drought risk analysis. For the purposes of this pilot, it was recognised that more complex indicators such as drought are likely driven by multiple environmental and physical factors. As such, our initial goal was to select and provide primary climate variable data that would be useful for deriving drought risks in combination with other inputs. Given that the primary input to drought models is precipitation, or lack thereof, we developed a data flow that extracted total precipitation per month and made this available both as a time series CSV and GeoJSON datasets, as well as OGC API features time series points. This climate scenario primary drought data was provided for the province of Manitoba and for Los Angelas. These two regions were chosen since we had pilot participants interested in each of these regions and in the case of Manitoba there is also a tie in to future work as this is an area of interest for the subsequent Disaster Pilot 2023.

For the Los Angeles use case, provided the Laubwerk Visualization component with climate change impact data that could help drive a drought impact that could affect their future landscape visualization model. The idea is that based on changes to climatic variables, certain areas may be more or less suited to different vegetation types, causing the distribution of vegetation to change over time. For more on their component, including example visualization results, please refer to section 7: From Data To Visualization.

In the case of this visualization component, simply providing precipitation totals per month were not sufficient to drive the needs of their vegetation model. In this case we did not have an intermediate drought model to feed climate variables to. In the absence of a more comprehensive drought model, we decided to develop a proxy drought risk indicator by normalizing the difference between precipitation from the past vs future climate scenarios.

Calculations were made using the difference between time series grids of projected precipitation and historical grids of mean precipitation per month. These precipitation deltas were then divided by the historical mean per month to derive a precipitation index. The goal was to provide a value between 0 and 1 where 1 = 100% of past mean precipitation for that month. Naturally this approach can generate values that exceed the range of 1 if the projected precipitation values exceed the historic mean. The goal was not so much to predict future absolute precipitation values but rather generate an estimated for precipitation trends given the influence of climate change. For example, this approach can help answer the question — in 30 years for a given location, compare to historical norms, by what percentage do we expect precipitation to increase or decrease. Laubwerk then took these results and used them as input to their landscape vegetation model which evaluates percipitation changes to determine whether the drought stress will cause a specific vegetation species to die out for a particular location.

Interesting patterns emerged for the LA area that we ran this process on deltas between projected and historical precipitation. While summers are typically dry and winters are wet and prone to flash floods. Initial data exploration seemed to show an increase in drought patterns in the spring and fall. More analysis needs to be done to see if this is a general pattern or simply one that emerged from the climate scenario we ran. However, this is the type of trend that local planners and managers may benefit from having the ability to explore once they have better access to climate model scenario outputs along with the ability to query and analyze them.

Figure 54 — FME Query Workflow: Geopackage precipitation delta time series to GeoJSON points

Figure 55 — FME Query Parameters: Geopackage precipitation delta time series to GeoJSON points

Figure 56 — FME Data Inspector: precipitation delta result showing potential drought risk for areas and times with significantly less precipitation than past

This approach is only a start and just scratches the surface in terms of what is possible for future drought projection based on climate model scenario climate variables. The specific business rules used to assess drought risk could be enriched and refined, or climate variables can simply be fed to external drought models as described below. FME provides a flexible data and business rule modeling framework. This means that as indicators and drought threshold rules are refined, it’s relatively straightforward to adjust the business rules in this component to refine our risk projections. Also, business rule parameters can be externalized as execution parameters so that end users can control key aspects of the scenario drought risk assessment without having to modify the published FME workflow. However one of the main goals of this pilot was not so much to produced highly refined forecast models for drought but rather to demonstrate the data value chain whereby raw climate model data cube outputs can feed a data pipeline that filters, refines, simplifies the data and ultimately can be used to drive indicators that help planners model visualize and understand the effects of climate change on the landscapes and environments within their communities.

To support future drought risk estimates for Manitoba, we also provided a precipitation forecast time series to Pixalytics as an input to their drought analytics and DRI component. Their component provides a much more sophisticated indicator of drought probability since in addition to precipitation it also takes into account soil moisture and vegetation. The goal was to extract precipitation totals per time step from the downscaled regional climate model (RCM) climate variable outputs for Manitoba based on CMIP5 (Coupled Model Intercomparison Project Phase 5) model results obtained from Environment Canada. For this use case the grids have a spatial resolution of roughly 10km and a temporal resolution a monthly time step. Pixalytics then ran their drought model based on these precipitation estimates in order to asses potential future drought risk in southern Manitoba. The data was provided to Pixalytics initially as a GeoJSON feed of 2d points derived from the data cube cells with precipitation totals per cell. We later also provided this same data feed as a OGC API Feature service.

For future phases of the climate or disaster pilots, it may be useful to explore additional approaches for both precipitation data analysis and combination with other related datasets and external models. It may be useful to segment cumulative rainfall below a certain threshold within a certain time window (days, weeks or months), since cumulative rainfall over time will be crucial for computing water budgets by watershed or catch basin. To do this we would like to test the use of a higher resolution time steps (daily), to see if the increased resolution reveals patterns that the coarser monthly time step does not. There are also other statistical RCM results that might be useful to make available (mean, min, max). Besides precipitation, climate models also generate soil moisture predictions which could used by to assess drought risk. This component would also benefit from integration with topography, DEMs and hydrology related data such as river networks, water bodies, aquifers and watershed boundaries. This would help increase the effective spatial resolution of impact projections by combining the coarser climate projections with higher resolution local factors such as elevation. Therefore rather than just computing precipitation deltas at the cell level, it would allow for assessing flood risks along rivers and water bodies, as well as provide the ability to evaluate precipitation by catch basin, and compute future cumulative trends that may indicate potential drought, flood, or derivative impacts such as irrigation or hydropower generation potential.

It should be stressed that the field of drought modelling is not new and there are many drought modelling tools available that are far more sophisticated than anything described above. As such, subsequent Climate and Disaster pilots should explore how future climate projections can be funneled into these more mature climate and impact models in an automated fashion to produce more refined estimates of projected drought risk. That said, we need to start somewhere, and it is hoped that this basic demonstration of the raw data to ARD to DRI value chain for drought can provide some insights into what type of indicators we may want to generate to help better understand future drought risks, and where we may want to improve on this process.

6.1.  Visualizing the Impact of Climate Change and Mitigation on Vegetation

One of the biggest challenges in communicating climate change is to tie global changes to the local impact they will have. Photorealistic visualization is a critical component for assessing and communicating the impact of environmental changes, and possibilities for mitigation. For this to work, it is crucial for visualizations to reflect the underlying data accurately and allow for quick iteration. In this regard, manual visualization processes are inferior. As much as possible, visualizations of real-life scenarios should be driven directly by available data of present states and simulations of possible scenarios. Our contribution is a first attempt at doing just that, determining what already works and what doesn’t with existing data and technology.

As our contribution to the Climate Resilience Pilot we explored such data-driven high-quality visualizations, focusing on the impact on vegetation. Due to the nature of this being a pilot, we constrained ourselves in terms of coverage area, to account for limited time and to cope with potentially limited data availability. This ensured that we were able to make the full connection from input data to final visualization, drawing valuable conclusions for broader application in the future. This size limitation will allow us to produce meaningful results if data transfer and processing is slow or even if it must be processed in manual or half-automated ways due to inconsistent formatting. It also lets us visualize a high level of detail without having to account too much for the sheer amount of data we could face with very large areas.

We selected a relatively small section of Los Angeles for actual visualization. The rationale behind this choice of location had several components:

• The given area that will (and already does) see considerable direct impact of climate change through heat, drought, wildfires, etc.

• It contains different areas of land use (from deeply urban and sub-urban to unmanaged areas).

• Since it is part of a major metro area, the results will be relevant to a large population base

• Some known mitigation measures that can be considered for visualization are in place.

• Other external (non climate change) known influences on vegetation, such as pests, irrigation limitations, known life spans of relevant plant species, etc.) are in play that could be considered.

6.1.2.  Results

The aforementioned data sources were combined to create a detailed visualization of the area in question. The pairs of images below show a visualization of the status quo as first image and then a composite of the four scenarios we visualized (one scenario per vertical stripe). The scenarios are projections of possible climate scenarios with and without mitigation measures in place and are in the following order:

1. Year 2045 without any mitigation measures. Plants that were likely to die off due to adverse climate events were just removed based on a probability.

2. Year 2070 without any mitigation measures with plants removed like in the scenario before.

3. Year 2045 with mitigation measures. Plants that were just removed in the two scenarios before have been replaced by plants that are more resilient and are part of the aforementioned initiatives for better climate resilience.

4. Year 2070 with mitigation measures with the same replacement logic as in the scenario before.

It should be stressed that these are visualizations of possible outcomes, but there are are many factors that make hard to make exact predictions! This contribution is merely meant as an example of how data could be used to drive scenario-based hyper-local visualization.

 
 
 
 
 
 
 
 
 
 
 
 
 
 

Figure 57 — Overview of the Visualized Region (Status Quo)

Figure 58 — Overview of the Visualized Region (Climate Projection With and Without Mitigation Scenarios as Described at the Start of the Results Section

Figure 59 — Above the Corner Sunset Blvd and N Curson Ave Looking North-East (Status Quo)

Figure 60 — Above the Corner Sunset Blvd and N Curson Ave Looking North-East (Climate Projection With and Without Mitigation Scenarios as Described at the Start of the Results Section)

Figure 61 — Corner Franklin Ave And N Sierra Bonita Ave Looking East (Status Quo)

Figure 62 — Corner Franklin Ave And N Sierra Bonita Ave Looking East (Climate Projection With and Without Mitigation Scenarios as Described at the Start of the Results Section)

Figure 63 — Corner Hollywood Blvd And Camino Palmero St Looking Looking North (Status Quo)

Figure 64 — Corner Hollywood Blvd And Camino Palmero St Looking Looking North (Climate Projection With and Without Mitigation Scenarios as Described at the Start of the Results Section)

6.2.  5D Meta World

Presagis offered the V5D rapid 3D (trial) Digital Twin generation capability to Laubwerk Presagis gathered open source GIS dataset for the Hollywood region in order to match the location of the tree dataset from Laubwerk Using V5D, Presagis created a representative 3D digital twin of the building and terrain. Presagis imported Laubwerk tree point dataset providing vegetation type information inside V5 Presagis provided V5D Unreal plugin to Laubwerk in order to allow the insertion of the Laubwerk 3D tree (as Unreal assets) into the scene. Using V5D, Laubwerk is capable of adapting the tree model in order to demonstrate the impact of climate change on the city vegetation

Presagis also provided to Laubwerk its V5D AI extracted vegetation dataset in order to complement the existing tree dataset as needed.

Figure 65 — image of the Presagis deliverable to Laubwerk. At this stage, all trees are using the same 3D model (palm tree). Laubwerk will use V5D to assign a representative 3D model based the on point feature attribution accessible in V5D. With V5D, this operation takes seconds to do and visualize the result in 3D.

6.3.  CRMA Web Application

Decision makers, public authorities, and citizens will primarily access data via a custom Esri web application, providing a simple dashboard interface for viewing interactive maps and graphs of the indices, and output formatted reports. The indices are grouped by 5 climate hazard types (Wildfire, Heat, Drought, Inland Flooding, Coastal Inundation). The current US project (https://livingatlas.arcgis.com/assessment-tool/explore/details) can be explored to gain context of what the global project will be.

Figure 66 — Climate Mapping For Resilience and Adaptation (CMRA) portal, US project view

Figure 67 — Climate Mapping For Resilience and Adaptation (CMRA) portal, showing number of max temperature for the period 2023-2064

The application also outputs formatted reports by county or census tract summarizing the data in a format easy to share with others.

Figure 68 — Application output reports

For each of those 5 climate hazards there is a corresponding StoryMap to further explain that hazard type, visualize the current and future hazard, and provide links to additional relevant resources.

• Extreme Heat: https://storymaps.arcgis.com/stories/5e482f11d2514191bb89c20638d98b3c

• Drought: https://storymaps.arcgis.com/stories/634ee231bb6743b88d23bda96fb838e9

• Wildfire: https://storymaps.arcgis.com/stories/ae2a8072429643f395f8f509df955ae6

• Flooding: https://storymaps.arcgis.com/stories/4ea811276aa641018f3a8d4e28585244

• Coastal Inundation: https://storymaps.arcgis.com/stories/f3ce292c0211400699b6e36985e561a6

6.4.  Ecere’s Client for NOAA’s Environmental Data Retrieval API

For the D100 Client Instance deliverable, Ecere enhanced its GNOSIS Cartographer geospatial client to better support visualizing and accessing multi-dimensional datasets, both from local sources and remote sources such as through OGC API standards. Support for the OGC API — Environmental Data Retrieval (EDR) standard as well as for OGC netCDF was implemented in the GNOSIS Software Development Kit. The GNOSIS implementation of the GNOSIS Map Tiles specification was also enhanced as an efficient format to store and exchange n-dimensional coverage tiles, including support for multiple pressure levels within a single tile packet. A pressure level selector control was added to the user interface, as seen below.

Figure 69 — Ecere’s GNOSIS Cartographer client accessing 4-dimensional CMIP5 air temperature dataset from GNOSIS Map Server, showing pressure level selector

Figure 70 — Ecere’s GNOSIS Cartographer client accessing 4-dimensional ERA5 relative humidity dataset from GNOSIS Map Server, showing pressure level selector

Technology Integration Experiments were performed with NOAA’s experimental EDR API deployment, providing feedback to its developers to help achieve conformance to the Standard, as well as help improving interoperability and usability. The results of visualization experiments with multiple data collections are shown below.

Figure 71 — Ecere’s GNOSIS Cartographer client accessing NOAA’s EDR API (nclimgrid-monthly collection, minimum daily temperature for January 2014)

Figure 72 — Ecere’s GNOSIS Cartographer client accessing NOAA’s EDR API (nclimgrid-monthly collection, minimum daily temperature for January 2022)

Figure 73 — Ecere’s GNOSIS Cartographer client accessing NOAA’s EDR API (nclimgrid-monthly collection, maximum daily temperature for January 2014)

Figure 74 — Ecere’s GNOSIS Cartographer client accessing NOAA’s EDR API (nclimgrid-monthly collection, maximum daily temperature for January 2022)

Figure 75 — Ecere’s GNOSIS Cartographer client accessing NOAA’s EDR API (nclimgrid-monthly collection, precipitations for January 2014)

Figure 76 — Ecere’s GNOSIS Cartographer client accessing NOAA’s EDR API (nclimgrid-monthly collection, precipitations for January 2022)

Figure 77 — Ecere’s GNOSIS Cartographer client accessing NOAA’s EDR API (NASA CMIP6 Global Daily Downscaled Projections collection, maximum temperature for January 14, 2014)

Figure 78 — Ecere’s GNOSIS Cartographer client accessing NOAA’s EDR API (NASA CMIP6 Global Daily Downscaled Projections collection, near-surface relative humidity January 15, 2014)

Figure 79 — Ecere’s GNOSIS Cartographer client accessing NOAA’s EDR API (NASA CMIP6 Global Daily Downscaled Projections collection, wind speed for January 15, 2014)

Figure 80 — Ecere’s GNOSIS Cartographer client accessing NOAA’s EDR API (NCAR Livneh gridded wind speed for January 15, 2013)

Figure 81 — Ecere’s GNOSIS Cartographer client accessing NOAA’s EDR API (NCAR Livneh gridded precipitations for January 15, 2013)

7.1.  Climate adaptation processes

One way to introduce adaptation processes is to frame them as a cycle (Figure 1). It starts with the evaluation of past, present, and future climatic conditions to define the exposure of a system to the impacts of climate change. Assessing the sensitivity of a system towards the impacts of climate change with local experts based on the exposure forms the second step. Thus, the risk of a system results from its exposure and sensitivity, based on which targeted adaptation measures can be implemented. Finally, the fifth stage is monitoring and evaluation. At this point the cycle starts over again.

Figure 82 — Adaptation Cycle

In the entire program, the focus is on supporting the communities to secure the living and economic space at the local level, which requires a well-founded assessment of the climate risks supported by local experts. The aim is to minimize risks, take necessary measures and raise awareness of precautionary planning, especially regarding the consequences of climate change.

The conducted evaluation focuses on one participatory element of adaptation cycles, the impact analysis workshops. The workshops aim to initiate stakeholder participation, raise local awareness of climate change impacts, gather expert input on sensitivity and implement an adaptation process that is widely accepted.

7.2.  Approach

alpS conducted a structured evaluation of available datasets of participatory processes with the aim to improve the level of information about climate change impacts and to identify the broadest accepted way of presenting user-related scientific statements. The assessment of adaptation cycles at different spatial levels allowed the further development and improvement of suitable interoperable solutions.

A set of questions was developed to measure the success of vulnerability workshops. This involved developing questions on workshop content (e.g., climate information, methodological approach) and permanence (e.g., adaptation measures implemented), in addition to external factors that influence workshop outcomes (e.g., political backing, human resources, time spent, financial commitment to adaptation, geographic conditions).

In a three-stage process, workshop participants were surveyed before the workshop, immediately after the workshop, and six months after the workshop. The following figure provides an overview of the survey process (Figure 2). In total, six representatives of communities or regions were asked for a pilot survey. Stakeholders of three of the communities and regions were interviewed shortly before the workshop, one community was interviewed immediately after a workshop implementation and two communities and regions were interviewed more than six months after their workshop participation. To supplement the comparatively small pilot survey, experiences from previous consulting cycles are also considered in the following.

Figure 83 — Three-part questionnaire

7.3.  Main results of interviews

In all surveyed municipalities or regions, it could be shown that the assessment of climate impacts must be done on the local level. Regional adaptation strategies and climate information provide a good overview and starting point for the municipal level. In topographically heterogeneous areas, such as mountainous areas, there is a need for assessments at the local level. It is therefore necessary to reassess climate impacts from a community perspective, considering the local risk landscape. A detailed consideration of the risks and the subsequent intersection of risks with the consequences of climate change is suitable to promote awareness, clarify the community’s concern, and facilitate the implementation of measures due to safety aspects. For this, climate information must be prepared accordingly. Climate data must not be too complicated but should not leave anything out. Especially climate impacts for which the community’s sensitivity is assessed in the vulnerability workshop by local actors must be accurate, consistent, and not duplicative. To achieve this, the climate impact chain will be introduced in the next section.

The abundance of content when initiating adaptation measures often leads to the community being overwelmed. The limitation to selected climate impacts is achieved through the identification of adaptation needs. This leads to the necessary focus on a few but urgent adaptation measures. The elaboration of measures must be done individually and in consideration of the communities’ ideas. Showing good examples of adaptation is useful and provides inspiration, however, in surveyed communities and regions mostly new measures were developed, which are exactly tailored to local conditions and needs. Necessary measures can partly be implemented directly by the municipality or only in cooperation with other actors (landowners, other municipalities, etc.). Both the development of measures and the process support must be carried out against this background.

Supporting communities throughout the process is essential. Equally important is the cooperation between local organizations and, scientifically sound external support that conveys seriousness and builds stakeholder’s confidence in the adaptation process. In addition, an active contact person with sufficient time resources is needed in each community to bring together the relevant actors and to follow up the topic beyond the events. Only in this way successful adaptation can take place.

7.4.  Improvement of the workshop setup and aspects of communication

As part of the Climate Resilience Pilot, alpS was able to optimize two aspects in the adaptation process. First, the creation of climate impact chains for different sectors was initiated. The climate impact chain improves consistency and the understanding of climate impacts. Second, the guideline to deal with external factors was developed. The pre-test conducted before the workshop, which specifically asks about these external factors, enables a direct response and preparation for dealing with not controllable factors in the process.

7.4.1.  Climate Impact Chain

In the current workshop design of the vulnerability workshops of alpS, local climate impacts are assessed on a matrix. The responses from workshop participants highlighted the importance of clear, unambiguous, and simple language when communicating climate impacts. Inspired by the responses of the workshop participants, the wording of climate impacts was optimized and broken down in the context of an impact chain from climatic effect to direct and indirect climate impacts (Figure 3). Thus, it is easy to understand which climatic effects drive climate impacts. This facilitates the data-driven assessment of the exposure of individual communities. In addition to the exemplary impact chain for the forestry sector shown in figure 3, further impact chains were created for all relevant fields of action in climate adaptation.

Figure 84 — Climate impact chain for the forestry sector

7.5.  Outlook: Stakeholders as a starting point for processing climate information

Overall, the consensus at the Closing Workshop in Huntsville was to focus more on stakeholder participation and to start from the stakeholders’ questions instead of the raw data. alpS is experienced in implementing and guiding participatory processes. In the coming project phase, alpS could offer a concept that enables data providers to identify their stakeholders, jointly define questions and collect targeted feedback.

7.6.  Summary

• Component: Climate communication and support for adaptation.

• Inputs: Selected climate indicators (past and future, different scenarios), cartographic data (hazard zones, population density, etc.), existing plans, strategies and concepts (regional development plans, climate protection strategies, previous analyses), and most important local climate and resilience information from stakeholders.

• Outputs: Target group-specific communication material (factsheets, graphs), description of the vulnerability and visualization of risk maps, adaptation measures, strategies for adaptation to climate change. In the context of this pilot alpS improved its communication methods and shared its findings to allow the Climate Community to copy and transform as many use-cases as possible to other locations or framework condition.

• What other component(s) can interact with the component: All components that deliver dri can interact with the component. Also, any component that needs user feedback or a test group, or that wants to develop data as part of a participatory process can interact with the component.

• What OGC standards or formats does the component use and produce: Processed local climate data, NetCDF.

8.1.  Drought Impact Use Cases

Based on the ARD, drought indicator, and data cube components, WHU develops three use-cases based on self-developed Open Geospatial Engine (OGE) for drought impact for rapid response to drought occurrences. Figure 85 shows the technical architecture of the OGE. It has the following features: 1) For data discovery, a catalogue service from OGE data center following OGC API is provided, allowing users to search geospatial data both available from WHU data stores and remote data stores. 2) For data integration, data can be integrated into the WHU software in the form of data cubes with three efforts: formalizing cube dimensions for multi-source geospatial data, processing geospatial data query along cube dimensions, and organizing cube data for high-performance geoprocessing. 3) For data processing, a processing chain is enabled in OGE using a code editor and modelbuilder. 4) For data visualization, a Web-based client for visualization of spatial data and statistics is provided using a virtual globe and charts.

Figure 85 — The technical architecture of the use-case for drought impact.

8.1.1.  Case study 1: Visualization for drought indicator

On the fundament of SPEI and OGE, we visualize the drought risk map on a virtual globe, as given in Figure 86 (a). The color matching of the visualization result is referred to the classification standard for the drought grade of SPEI illustrated in the table. The red and orange area in the visualization result represents a trend of drought (SPEI≤-0.5), while the green and blue represent wetness. The SPEI is calculated for each month of the input dataset, and users can visualize the SPEI of any month on the virtual globe for flexible drought analysis. Meanwhile, the use case also supports cubes-based SPEI visualization for time series drought analysis as given in Figure 86 (b), where the height of the cube is a range of time arranged in order of month, and each layer in the cube represents drought impact of one month.

Table 15 — Gradations of drought specified by SPEI

Grade	Type	SPEI Value
1	Normal	-0.5<SPEI
2	Light drought	-1.0<SPEI≤-0.5
3	Moderate drought	-1.5<SPEI≤-1.0
4	Severe drought	-2.0<SPEI≤-1.5
5	Extreme drought	SPEI≤-2.0

Figure 86 — Visualization of SPEI on a virtual globe.

8.1.2.  Case study 2: Drought Risk analysis of Yangtze River basin

In the summer of 2022, an extreme drought hit the Yangtze River basin, posing huge impacts on agriculture, the ecosystem, and human livelihoods. It developed rapidly in the upper, middle, and lower reaches of the Yangtze River, intensifying on a large scale in 10 provinces (municipalities) in the basin (https://doi.org/10.1002/rvr2.23). The water area of Poyang Lake has been reduced by 90%, threatening the habitat for fish and migratory birds, etc. To analyze drought trends in the Yangtze River Basin, we visualized monthly SPEI for 2022, as shown in Figure 87. From the Figure, it can be seen that the drought index in the Yangtze River Basin has been rising since March. In July, the drought risk map turned light yellow, indicating a moderate drought. In August and September, the drought further intensified and reached an extreme drought situation. In October, the drought eased somewhat, and it had subsided mainly by November.

Figure 87 — Drought risk map in part of China.

8.1.3.  Case study 3: Drought risk analysis of Poyang Lake

Due to the extreme drought in the Yangtze River Basin, the water inflow into Poyang Lake, the largest freshwater lake in China, declined dramatically due to continuous hot weather with little rain since early summer. Hence, we developed a use case of drought analysis applying multi-source SR ARD.

In this use case, we collected Sentinel-2 SR and Landsat-8 SR, and produced Gaofen-1 WFV SR data in the center area of Poyang Lake (As shown in Figure 88) before and during the drought period. NDWI indices were calculated to monitor water area changes in Poyang Lake. Water bodies typically exhibit positive NDWI values, making it an effortless method to extract water areas. As illustrated in Figure 89, the first column represents Poyang Lake before the drought, while the last three columns represent Poyang Lake which was currently experiencing the drought. It is evident from the RGB composite that the water body of Poyang Lake has significantly decreased due to the drought weather. The water body extraction results by NDWI indicate that from May to October, the water area in the study area decreased from ~1800 square kilometers to ~350 square kilometers, representing a reduction of ~ 80% in water area.

Figure 88 — The study area of the Poyang Lake case.

Figure 89 — The changes in Poyang Lake before and during the drought period.

---

8.2.  Analysis Ready Data (ARD) Use Case

8.2.2.  Approach

The client instance is implemented as a Web application to support the creation and delivery of ARD for climate change impact assessment.

The Carbon Portal conducted data discovery and access in two steps:

• step 1: Data collection search

• step 2: Granule search to search granules in the collection

ARD services are enabled on results of granule search if the collection is an ECV. If the ECV data provider has implemented the WCS service for the dataset, the portal will directly communicate with ECV provider’s WCS server for ARD service. If the ECV data provider does not have the WCS service, the portal’s server will download entire granule and stage it on the portal server to provide ARD service.

Most of ECV data provides don’t provide such service.

Figure Figure 90 shows a software architecture of the CEOS WGISS Carbon Community Portal.

Figure 90 — Software Architecture

ECV Inventory v4.1 records are converted as a unified form of the portal predefined metadata format by a converting tool. Retrieve collection metadata for ECV entries from CWIC/FedEO OpenSearch referred by Data Record Information. There is 1251 ECV inventory records (Same as WGClimate, 870 for Existing, 381 for Planned). The portal supports totally 1910 predefined ECV relative collection datasets from ECV Records.

ARD service for ECVs in case that providers have no WCS services:

• Support when user select one granule entry

• Download granule dataset file from given repository, and manipulate it for serving WCS

• Stage the data in portal backend server and generate a list of all coverages in the granule

• User specifies the specifications of data to download

• User obtains the customized data by downloading via WCS GetCoverage request

ARD service for ECVs with data providers’ WCS:

• Directly talk to provider’s WCS

• Without granule downloading and stage steps in the portal’s backend server.

8.2.3.  Use Case: The climate change impact on crop production in Turkmenistan

The use case of the climate change impact on crop production in Turkmenistan. However, the portal can switch to another use case or support multiple use cases if this pilot requests us to do so.

Drought is one of the major climate-related natural hazards that cause significant crop production loss in Turkmenistan. Climate change increases the risk of drought in Turkmenistan. Crop models (such as WOFOST) are often used to support the decision-making in long-term adaptation and mitigation. The client will be used to prepare data to be readily used as parameters and drivers in such modeling processes. Drought impact analysis data may include long time series of precipitation, temperature, or indices for crop conditions, water content, or evapotranspiration. Many of these climate data and products from satellite sensors are served at NASA’s Goddard Earth Sciences Data and Information Services Center, such as GPM data products, MERRA assimilated climate data. These will be used in the case of drought impact assessment in Turkmenistan.

The drought impact ARD case will demonstrate:

1. Applicability of open standards and specifications in support of data discovery, data integration, data transformation, data processing, data dissemination and data visualization

2. Transparency of metadata, data quality and provenance

3. Efficiency of using ARD in modeling and analysis

4. Interoperable dissemination of ARD abiding by FAIR principles

The searching is starting with the following information:

• Keyword: surface soil moisture

• Filter: daily

• Date: 10/1/2021, 10/1/2020, 10/1/2019, 10/1/2018

• Area: Turkmenistan (Bbox: 52.264(Left), 35.129(Bottom), 66.69(Right), 42.8(Top))

Choose a collection dataset:

Groundwater and Soil Moisture Conditions from GRACE and GRACE-FO Data Assimilation L4 7-days 0.25 x 0.25 degree Global V3.0 (GRACEDADM_CLSM025GL_7D) at GES DISC

Choose the following granule data file:

GRACEDADM_CLSM025GL_7D.3.0:GRACEDADM_CLSM025GL_7D.A20220926.030.nc4 (for year 2022)
GRACEDADM_CLSM025GL_7D.3.0:GRACEDADM_CLSM025GL_7D.A20210927.030.nc4 (for year 2021)
GRACEDADM_CLSM025GL_7D.3.0:GRACEDADM_CLSM025GL_7D.A20200928.030.nc4 (for year 2020)
GRACEDADM_CLSM025GL_7D.3.0:GRACEDADM_CLSM025GL_7D.A20190930.030.nc4 (for year 2019)

Retreve the file and choose a variable:

sfsm_inst (Surface soil moisture percentile)

Adjust legend color (0 is the least soil moisture), and get the following results:

Figure 91 — Surface soil moisture percentile (year 2019-2022)

8.3.  Solar climate atlas for Poland

The project aims at creating analysis ready solar radaition data cube and web map service for Poland to advance development of the solar-smart society and economy and to provide know-how and tools, which are easily reusable in other geographical regions worldwide, in accordance with the FAIR principles.

The project will update a previously created solar climate atlas for Poland by:

• increasing spatial and temporal resolution of the datasets: 0.05° x 0.05° degrees (regular lat/lon grid) → 100×100m Monthly means → Daily/Hourly(tbc) means

• extending time period: 1991-2014 (24 yrs) → 1983-2022 (40 yrs)

• replacing static maps with a dynamic and interactive interface

• using practical solar radiation parameters instead of physical variables

• making datasets (+ metadata) available for downloaded in interoperable file formats (for further use)

• providing solar climate knowledge base and data/service user guides

in order to:

• advance development of the solar-smart society and economy in Poland

• provide know-how and tools, which are easily reusable in other geographical regions

Figure 92 — Solar Climate atlas for Poland available on the IMGW website: https://klimat.imgw.pl/en/solar-atlas

Newly created solar climate data cube and web map service will be more FAIR as they will be made available online, possibly on the official website of the Polish Hydrometeorological Service (IMGW) for an increased findability, upon future agreement (to be discussed) to make them more Findable by the general public. The whole process of data access (including authentication) will be transparent and accompanied by appropriate instructions so that the Accessibility could be much higher. The format of the datasets in the data cube will be an OGC netCDF standard compliant with the CF (Climate and Forecast) convention, which is suitable for encoding gridded data for space/time-varying phenomena and commonly known in the climate science community but also easily readable with other common spatial data processing and visualization software including most of the GIS software to keep fully Interoperable. Finally, even though the proposed solar climate information system (maps+ dataset) are limited to the area of Poland, all processing scripts will be made available on github along with a well-described processing steps (both Jupyter notebooks and instructional videos will be considered) to provide Reusability for other countries or geographical regions.

It is important to emphasise the importance of solar radiation studies in addressing the impact of climate change. Solar activity is not responsible for the global warming trend we have been experiencing in recent decades. The Sun is however primary energy source driving most of the processes in the Earth’s climate system. This energy can also be used as a renewable source of electrical energy. Therefore knowledge about spatio-temporal distribution of surface incoming solar radiation is crucial for decision making in the sustainable energy transition process which allow both to rationalise energy consumption and reduce emissions of greenhouse gas (responsible for the warming effect).

Scope of work for the Climate Resilience Pilot: State-of-the-art review and exploratory data analysis

Objectives for the Climate Resilinece Pilot #1 are:

• to document existing solar radiation datasets (satellite, model and reanalysis data) and services (both freely accessible and commercial)

• to verify the accuracy of the in situ measurements and satellite climate data records for the selected solar radiation parameters using proper statistical methods

Different solar radiation climate data records and their characteristics have been listed in the table below.

Table 16 — Solar radiation climate data records

All the solar radiation datasets listed above cover the area of Poland but are rather not ready for direct use by a non-scientific users. They are pre-processed to meet the requirements for climate data records and quality controlled but still primarily addressed for further scientific use. Even though open source tools for managing and exploiting these datasets are often delivered by the data providers, they are not always sufficiently “attractive” due to an extensive workload, which is still required in order to make them easily integrable with additional data from other sources and ready for specific applications in support of policy- and/or decision-making processes at national level.

CM SAF SARAH-3 dataset meets all the requirements for the planned solar climate data cube and web map service in terms of quality of estimates, spatial resolution and temporal coverage. Its accuracy is now being verified in more detail against in situ measurements for the selected solar radiation parameters using proper statistical methods.

The following table includs a selection of existing solar climate web map services.

Table 17 — Solar climate web map services

Identified services provide generalised information on spatio-temporal solar radiation patterns (high resolution grids for longer period not available at all or not for free!). A set of high-resolution analysis-ready data products in user-friendly formats dedicated to specific applications at national level are needed to support decision-making processes.

The identified solar radiation services are currently being analised in terms of overall functional scope, usability of the interface, innovative tools and possible shortcomings. The results of this analysis will be verified against detailed recognition of the potential user needs.

8.4.  Wildfire resilience in insurance

The main focus of IFC’s participation to this project is to better understand end-to-end hazard and risk modelling workflows, in turn supporting the climate services required for decision-making in the business. This participation is also intended to further open up Intact Lab to the outside world, by exchanging information on wildfire risks and climate resiliency in the context of the insurance industry.

The project centered the efforts around these challenges:

• Identify current usages of wildfire maps at Intact by interviewing various business units;

• Revisit and update previous wildfire hazard map, using external open data sources;

• Identify and seek collaboration opportunities with pilot participants;

• Inform internal architectural, infrastructure and procurement processes of new geospatial standards and trends;

• Identify and develop insurance wildfires risk use cases to help build resilient communities.

These activities should align with the best practices and standards of the OGC and current and proposed themes in OGC’s climate resilience Domain Working Group (DWG).

Wildfire risk in Canada is prominent and even though major events do not occur every year, they can cause unprecedented damage. Costs from the wildfire events of summer 2021 in British Columbia reached $77 and $78 millions in insured damage at White Rock Lake and Lytton, respectively (https://doi.org/10.5194/nhess-12-3519-2012). Wildfire activity is expected to go up due to an increase in fire-prone conditions across the country (https://doi.org/10.5194/hess-21-6329-2017).

In an insurance company, wildfire risk impacts the work of a wide array of users, such as claim adjusters, insurance brokers, engineers, data scientists, actuaries, portfolio managers, and executives. IFC’s stakeholders were invited to provide information about current and potential uses of wildfire risk products within their operations. This information was used to identify use cases supporting this pilot project, as well as prospective proof-of-concepts for wildfire resiliency. It was determined that wildfires can impact numerous activities in the business, including but not limited to restoration, claims, portfolio management, CAT modelling, risk management and loss prevention. A resiliency and adaptation use case relevant to the topic of climate resilience is presented below.

Through granting programs, Intact is investing in communities across Canada to protect people from the effects of climate change and build more resilient communities (ESIP: Attribute Convention for Data Discovery (ACDD) – http://wiki.esipfed.org/index.php/). The Regional Municipality of Wood Buffalo and the community of Lac La Biche are both at an increased risk of being affected by wildfires. Their respective programs provide rebates and other incentives to residents to participate in home FireSmart assessments, and to upgrade their homes.

Figure 93 — FireSmart Canada’s Home Ignition Zones (Lawrence Livermore National Laboratory: NetCDF CF Metadata Conventions – http://cfconventions.org/)

Homeowners are informed of building materials options in the immediate zone to reduce their risk of serious property damage. Residents and communities are also presented with landscaping practices for the intermediate zone, further helping reduce the risk of wildfires in the area. The Acadia First Nation’s member communities are acting in the extended zone, creating 10 to 30 meters fire breaks to increase time for emergency response in case of fire and decrease the risk of fire spread.

Ignition zones can be seen as interfaces between individual homes or structures, and the surrounding area. In the scientific literature, the area where wildland meets or mixes with human-built structures is called the Wildland-Urban Interface (WUI). As the WUI is the area that is the most at risk of wildfire, it is important to closely consider it when modelling risk. The first WUI dataset for Canada was generated in 2018, and it was identified that 3.8% of the national land area is located in the WUI (https://doi.org/10.5220/0006681102050210).

Figure 94 — Wildland-Urban Interface for Canada, on the left. Extraction of the WUI using satellite-derived imagery, on the right (https://doi.org/10.5220/0006681102050210).

A more comprehensive view of the WUI considers industrial areas as well public infrastructures, such as power lines and railroads. This area is called the Wildland-Human Interface (WHI) and covers 13.0% of the national land. It is estimated that within the WHI, 19.4% of the area is in zone of wildfire recurrence ≤ 250 years (OGC: OGC 11-165r2: CF-netCDF3 Data Model Extension standard, 2012). By the end of the century, this number could increase to 28.8% under Representative Concentration Pathway (RCP) 2.6 low emissions scenario, and to 43.3% under RCP 8.5 high emissions scenario. Integrating WUI in climate scenarios can help conduct portfolio stress testing and evaluate future risk.

As cities will keep sprawling as population increases, the WUI is also expected to grow. This is an issue since increased fire activity due to climate change is to be expected. Furthermore, this increased exposure will reach more vulnerable communities. It was shown that WUI is significantly related to socioeconomic variables such as GDP per capita, population density, road density and proportion of population above 65 years old (https://docs.ogc.org/is/14-083r2/14-083r2.html).

The Canadian WUI dataset (https://doi.org/10.5220/0006681102050210) is unfortunately not available for download but could be replicated with open data sources, for instance through Natural Resources Canada (NRCAN) spatial infrastructures. When developing a WUI dataset, an important parameter for users to finetune is the ember transport distance. Values can vary between the median value of maximum travel distances, which is 600m (https://doi.org/10.3390/fire3020010), and the maximum travel distance of 2400m which is the official standard in the United States. Novel wildfire risk models can also dynamically adapt fuel classes within the WUI to represent propagation more accurately. Producing, hosting and integrating WUI datasets can therefore support creation of better risk indices, but also help identify vulnerable areas to support further adaptation.

8.5.  Climate Resilience for Coastal Ecosystems

The following use case(s) examine various scenarios designed to qualify the risks and pending impacts of climate change to coastal ecosystems. The scenarios are designed to leverage Analysis Ready Datasets combined with in-situ observations to draw direct relationships between a changing environment and dependent human activities.

The core of this exercise is focused on the application of OGC standards & specifications as adapters to accessing various datasets supporting key ocean and coastal climate indicators.

10.1.  Technical aspects: Climate resilience information systems towards FAIR Climate services

Issues around the delivery of climate information to support adaptation decisions to facilitate the difficult and time-consuming work of climate service centers. These centers may have a local, regional or international scope, but typically act as boundary organizations, connecting clients to climate science data and expertise. As demand increases for climate products, climate service centers are pressured to develop and deploy IT systems to access and process climate data more efficiently and expand the range and complexity of services they deliver. Although climate adaptation challenges vary across regions, data processing workflows are very similar and could benefit from shared information systems. Land Degradation Neutrality (LDN) and climate resilience are strongly related to the scientific phenomenon as well the technical applications regarding the value chain from raw data to information and knowledge. In both cases, similar approaches have been developed concerning data handling in datacubes, analysis-ready data (ARD) up to the decision-ready indicators (DRI). Agreeing on standards regarding DataCube, ARD, and DRI would enable a better linkage between the information exchange within the UN climate policy frame and beyond.

Interoperability studies and gap analysis of data sources and infrastructures. Here, especially, the Copernicus Climate Change Service (C3S) with its underpinned Climate Data Store (CDS) is an example that has been renewed and moved into higher interoperability. A dedicated gap analysis and interoperability experiment concerning the usability of the C3S technical services inline with existing other climate resilience information systems would be a useful step towards the vision of global collaborative solutions. In this aspect, the concept of FAIR Climate services can be refined, extended and properly documented.

It is further recommended to progress lowering the barriers for experts who want to spin off climate resilience information systems for their specific use cases and needs. As demonstrated in the pilot, the modular chaining of components is the recommended approach to design the architecture, with climate application packages being interoperable with each other and following the FAIR Climate Services principles. There are existing utilities (birdhouse approach demonstrated in this pilot) helping developers to establish climate application packages that need to be further developed and improved for better usability. Equality to climate application packages, the concept of LDN value chain is following the same approach of modular interoperable components where interoperability can be enhanced.

It is further recommended, that aspects of data visualization and the use of case-specific simulations need to be emphasized. Especially the small-scale 3D visualizations, including realistic digital twins of vegetation, and respective trees in digital twins of urban areas are recommended to be enhanced in the future. The pilot has shown the power of artificial intelligence to establish realistic simulations of use cases under different climatic scenarios. Enhancing the technology behind, and establishing the data visualisation and simulation for specific use-cases, political decisions or socioeconomic scenarios with respect to future climate projections would be a step forward in closing the gap between existing climate information and implemented climate action.

10.2.  Climate Service Consultation aspects: Communication to Stakeholders

The upcoming CRP24 should will have a user-centric approach, to tailor the data products and application packages and optimize them to the user needs and requirements. The existing OGC stakeholder community should be more strongly included during the pilot execution to tailor the value chain from raw data to information according to the stakeholder requirements. It is recommended to design the OGC pilots with activities addressing potential stakeholders to grow the OGC Stakeholder community as well as to understand their requirements and address data products and tools related to their needs; further bridging the gap of scientific knowledge to policy-driven climate action. The huge amount of knowledge about climate change and its potential impact and the relatively low socio-economic change, called the knowing-doing-gap, can be addressed in future work. The improvement and incorporation of the communication aspects explored in the current pilot should be emphasized and enhanced with existing technologies; especially simulations and data visualization. Also, the proposed good practice guidance of the UNCCD is proposing ‘decision trees’ for end users to identify the most reliable data that exist for a region.

OGC needs to continue to move towards non-technical communication; breaking down the very technical engineering reports into non-technical content, like animation videos. Especially for the domain of climate and disaster resilience, the understanding of the principle importance for the work concerning FAIR Climate services is essential to be presented in other formats than only engineering reports. Besides explanation videos, capacity building can be done with modules in e-learning platforms that are currently being established in OGC. Future pilots should output tutorials and training materials to lower the barriers for developers by spinning off their applications based on good practice guidelines, tutorials, and e-learning modules. In this context, established running applications can be promoted over the upcoming open science persistent demonstrator. It is recommended to tailor capacity-building material in formats that are exchangeable with other open knowledge platforms like the GEO Knowledge hub. A further aspect of capacity building and reaching out is to move the upcoming work into multiple languages. The animation video of this pilot has already been realized in four languages; besides English, it is available in French, Spanish, and Chinese. Upcoming future work should not be restricted to only English, but targeting to other languages as well.